Beiträge von Normalseher

Hallo zusammen,

kleines Update von mir.

Ich verwende jetzt seit 3 Monaten u.a. folgendes System:
x86-Mini-ITX (Asrock J3160TM-ITX mit Versorgung aus Notebook-Netzteil)
Technotrend CT2-4400-v2 DVB-Stick
System, Timeshift, Recordings etc. auf gemeinsamer SATA-HDD, LE Standardinstallation
LE 8.2.3
VDR 2.2.0

Diese kleine Kiste läuft praktisch perfekt. Ich kann mich nicht erinnern, in den 3 Monaten einen Fehler beim Timeshift bzw. Skip oder auffällige Bildfehler beobachtet zu haben, oder einen anderen relevanten SW-Fehler.

Use-Cases: DVB-C TV live, TV Timeshift, TV Recordings, Videoplayback, manchmal Youtube

Danke für deine Einschätzung, don. Hab' ein passendes SATA Plättchen bestellt.

Hallo zusammen,

kürzlich habe ich mir ein x86 Mini-ITX Kodi-System aufgebaut, alles läuft perfekt, keine Probleme.

Für ein zweites x86-System überlege ich, ob ich wirklich eine "große" SATA HDD neu kaufen muss, oder ob ich stattdessen eine bereits vorhandene "große" USB-HDD als Storage, und eventuell eine zweite kleine vorhandene SATA-HDD als Systemlaufwerk, verwenden kann. Beim ersten System ist eine gemeinsame große SATA-HDD für alles eingebaut.

Ich bin bei meinen Versuchen an zwei verschiedenen x86-Rechnern auf das Problem gestoßen, dass beim Hochfahren offenbar das Mounten einer externen USB-HDD zu spät (?) erfolgt, und deshalb (?) auf der Platte befindliche TV-Aufnahmen nicht im "Live-TV/Aufnahmen"-Dialog angezeigt werden: dieser ist immer leer. Beim Rechner mit SATA-Platte habe ich dieses Problem nicht. Die Aufnahmen selbst sind ok, über "Videos" lassen sie sich abspielen. Eine neue erstellte Aufnahme taucht auch zunächst korrekt im Aufnahmen-Dialog auf, nach dem nächsten Reboot aber nicht mehr.

Die Vermutung, dass dieses am verspäteten Mounten des USB-Laufwerks liegen könnte, kommt daher, dass die Meldung "Wechseldatenträger eingebunden" erst ca. 3-5 Sekunden nach Aufbau des Kodi Homescreens erscheint.

Soweit ich gelesen habe, ist ein manuelles frühzeitiges Mounten in autostart.sh nicht ganz so einfach möglich (irgendwelche "Regeln" scheinen da problematisch zu sein?)

Ist meine Beobachtung ein typisches Problem mit Aufnahmen auf einem USB-Laufwerk? Oder mache ich was falsch?

Wenn dieses gelöst wäre, dürfte doch nichts dagegen sprechen, ein USB-Laufwerk als Recording-Platte zu verwenden? Ich vermute, dass es sogar gehen müsste, auch LE/Kodi darauf zu installieren, also außer der USB-Platte kein anderes Laufwerk im System zu haben?

Da -soweit ich weiß- das Booten von einem USB-Laufwerk relativ lange dauert (da die einzelnen USB-Ports vom Bios bis zum Timeout auf bootfähiges Laufwerk gepollt werden?), kam ich auf den Gedanken, das System vielleicht besser auf eine kleine SATA-Platte zu packen.

Oder sollte ich doch lieber das Geld für eine große SATA-Platte in die Hand nehmen, um nicht immer wieder irgendwelche Problemchen mit einer "exotischen" Konfiguration zu haben?

Für Tips bin ich dankbar!

Okay, die Timeshift-Artefakte gibt es immer noch mit TVH 4.2 und LE 9. Wie vorher: manchmal ewig lang nicht, und dann dauernd.

Was ich oben zur ruckligen Wiedergabe am Raspi geschrieben habe, muss ich zurücknehmen: die Bildraten-Einstellung für TV wird offenbar vom Hz-Wert bei "System/Anzeige/Bildwiederholrate" übernommen, und nicht über "Wiedergabe/Videos/Bildwiederholfrequenz anpassen" automatisch gesteuert. Jedenfalls läuft es mit Einstellung 50 statt 60 Hz deutlich flüssiger.

Ich werde wohl bis auf Weiteres am x86 das dort einwandfreie VDR verwenden, und am Raspi Tvh (und versuchen, dort über die Timeshift-Fehler hinwegzusehen).

Die Tvh 4.3 + 8.2 teste ich aber noch, ebenso das VDR 2.3.8 + v9-Milhouse

Kleines Zwischenfazit mit v9 #0124 und dem dazugehörenden Tvheadend 4.2, am HTPC:

- Die beiden "Endanschläge" beim Timeshift sind implementiert. Aber es gelingt nicht immer, wieder exakt den Live-Mode zu treffen. Im Vergleich mit dem Raspi-System im Nebenraum hatte ich manchmal ca. 1 s Nachlauf hinter dem Live-Bild, den man mit Skip nicht immer beseitigen konnte. Die Anzeige rechts von der Zeitleiste springt dann im Wechsel auf -00:01 bzw. verschwindet (was offenbar "Live" bedeutet).

- Nach Skip häufig holpriger Anlauf für ca. 5s (ruckelnd, teilweise Bild/Ton asynchron), dann immer für ca. 8 s Einfrieren, bis es schließlich weitergeht. Während der Gedenkzeit erfolgt kein Plattenzugriff.

- Es ist mir bisher nicht gelungen, einen Skip-Fehler oder permanentes Einfrieren zu provozieren. Aber einmal hat es den DVB-Stick zerlegt (keine Daten mehr). Reboot half nix, Stick raus und rein hat funktioniert.

- Ich habe bisher keine Artefakte im Timeshift gesehen. Ein Test mit gut gefülltem Puffer steht aber noch aus.

Werde ich ausprobieren!

Am Raspi habe ich inzwischen herausgefunden, dass die großflächigen grünen Artefakte mit VDR nur, aber immer in der TV-Ausgabe entstehen. Sie sind live, im Timeshift, und beim Abspielen der Aufnahme reproduzierbar zu sehen. Sie sind aber NICHT zu sehen, wenn ich das Timeshift-File oder die Aufnahme auf einem anderen Rechner z.B. mit VLC abspiele. Zu den betroffenen Zeitpunkten treten dort "nur" lokale Klötzchen auf. Es scheint also auch ein Decodier- oder Anzeigeproblem von VDR (oder Kodi?) auf dem Raspberry zu geben (empfindlichere Reaktion auf Datenfehler?).

Außerdem bin ich inzwischen sicher, dass mit TVH und VDR am Raspberry bewegte Szenen ruckliger laufen, als mit TVH oder VDR am HTPC. Ob dieser Unterschied auch in den Aufnahmen drin ist, versuche ich noch rauszufinden (der Unterschied, wenn es ihn gibt, ist zumindest nicht offensichtlich). Ich will auch noch testen, ob es am DVB-Stick <-> DD-Karte oder an der HW-Plattform liegt.

Erst mal werde ich jetzt aber TVH unter v9 antesten, ob sich beim Timeshift-Verhalten eine Verbesserung zeigt.

Oh nein, es ist so einfach und doch so unerwartet...

Hier steht folgender Hinweis:
"ACPI-Wakeup ist verwandt mit der BIOS-Option "Wake on RTC", bei der man im BIOS eine Aufwachzeit einstellt. Diese Option muss je nach Mainboard mal aktiviert, mal deaktiviert sein, damit ACPI-Wakeup funktioniert."

Erkenntnis: Beim Gigabyte GA-H81M-HD3 muss "Resume by Alarm" auf Disabled gesetzt werden. Und schon klappt das Aufwecken...

Vielen Dank für deine Hilfe, und natürlich auch für das schöne Add-On!

Inzwischen habe ich folgendes getestet:

Aufnahme geplant für 4.2.2018 um 20h15 (-1 Min)

Wenn ich dann runterfahre (mit erscheinender Meldung zur Timer-Programmierung: 20h14), dann den Rechner wieder manuell am Power-Button starte, und dann über SSH ausführe:

HTPC:~ # cat /proc/driver/rtc
rtc_time	: 17:30:27
rtc_date	: 2018-02-04
alrm_time	: 00:00:00
alrm_date	: 2018-02-05
alarm_IRQ	: no
alrm_pending	: no
update IRQ enabled	: no
periodic IRQ enabled	: no
periodic IRQ frequency	: 1024
max user IRQ frequency	: 64
24hr		: yes
periodic_IRQ	: no
update_IRQ	: no
HPET_emulated	: yes
BCD		: yes
DST_enable	: no
periodic_freq	: 1024
batt_status	: okay

Würde also nicht passen, aber vielleicht sind das Standdardwerte, die beim Booten eine vorhergehende Programmierung überschreiben?

Zu deinen Fragen:
- LE 8.0.2 (wegen der Digital-Devices Treiber; eine v9 habe ich noch nicht wirklich zum Laufen gebracht). Zu alt? Ich könnte versuchsweise auf eine 8.2.3 mit anderem Tuner umstellen, wenn das aussichtsreich ist.
- Gigabyte GA-H81M-HD3 mit Celeron G1840 (von 2014)
- ACPI: dazu finde ich keinerlei Angaben oder Einstellungen im BIOS, außer das mit Windows-8. Kann das sein, oder muss es irgendwo versteckt doch etwas dazu geben? Das MB-Manual sagt: ACPI 2.0a
- Aufwachmethode? Ich finde nur "Abschaltung erfolgt durch... Kodi" (?)

Edit: Hab doch was im BIOS gefunden:

XHCI mode: "Allows you to determine the operating mode for the xHCI controller in OS"
(Auto, SmartAuto, Enabled, Diasabled, Manual)
Stand bisher auf SmartAuto.

Hallo BJ1,
danke für die schnelle Hilfe!

Jetzt funktioniert das Aufrufen über F12 und den Powerbutton der Fernbedienung (es erscheint die Meldung über die programmierte Aufweckzeit). Aber das Aufwachen selbst funktioniert leider immer noch nicht.

Ich weiß, dass das Mainboard das kann, weil mit einer Win-10 Installation dieser Rechner oft mitten in der Nacht zum Update hochgefahren war.

Im Bios selbst sehe ich keine verdächtigen Einstellungen. Den Windows-8 Mode habe ich auf "Other-OS" gesetzt. Konkret zu ACPI finde ich nichts. Es gibt eine Eingabemaske für die Wakeup-Zeit, wo alle Felder auf 0 stehen. Ob diese Maske aber nur zum Setzen oder auch zum Auslesen funktioniert... k.A.

Kann man nach manuellem Start von LE auslesen, ob der Bios-Timer vorher programmiert wurde, oder wird die Programmierung grundsätzlich beim Booten gelöscht?

Hallo,

wo könnte ich denn nachschauen, wenn das Aufwecken nicht funktioniert?

Im BIOS ist eingestellt: Wake on... RTC alarm
in Kodi: Funktion für Ausschalten ... Ausschalten / Energiesparen-aktiviert... Nein
im RP manager: Abschaltung erfolgt durch... Kodi

Ich fahre herunter über den Kodi-Ausschaltbutton, in den S5.
Das Backend ist VDR.

Der Rechner startet leider nicht zur gewünschten Zeit

In den Kodi-Logfiles [definition='1','0']log[/definition] /[definition='1','0']log[/definition].old finde ich im Zusammenhang mit dem Herunterfahren keine relevanten Einträge. Müsste dort was erscheinen?

Ich habe im RP-manager aktiviert, dass der nächsten Aufwachzeitpunkt angezeigt werden soll. Zumindest beim manuellen Herunterfahren von Kodi erscheint aber nichts...?

Woran könnte es liegen?

Danke für die Info! Mit dem Tvh Server hat es funktioniert, mit dem Client leider noch nicht.

Hallo,

ich hänge gerade am gleichen Problem, mit der gleichen Fehlermeldung. Hatte es zunächst unter der Milhouse-Version 0202 versucht, jetzt unter 0124. Muss man irgendwo einstellen oder etwas anderes machen, wenn man Addons für eine Milhouse-Version installieren will?

Benutzerdefinierter Kanal und Update-Kanal sind auf milhouse.librelec.tv... bzw. Milhouse 9.0 eingestellt.

Konkret funktioniert die Installation von Tvheadend nicht. VDR hatte auf üblichem Weg geklappt.

Welche der aktuellen Milhouse v9 Versionen ist für den täglichen Betrieb empfehlenswert?

Ich habe auf dem HTPC zunächst LE 8.2.3 installiert, um zu testen, wie sich die DVB-Tunersticks am x86 verhalten. Ergebnis: die 3 Typen (Technotrend CT2-4400-v2, Edision Opti-Combo, X-Box One Tuner) funktionieren am x86 alle besser als am Raspberry, im Sinne von nahezu keine (Xbox) bis gar keine Artefakte mehr. Besonders beim VDR-Backend ist der Unterschied zum Raspberry sehr auffällig (dauernd grünflächige Bilder <-> perfekt), aber auch mit TVH ist der Empfang am PC deutlich besser!

Erkenntnis 1:
VDR-Backend + DVB-Tunerstick + Raspberry + 720p ---> Bildqualität unbrauchbar (grüne Artefakte)
VDR-Backend + DVB-Tunerstick + x86 + 720p ---> Bildqualität einwandfrei
TVH + DVB-Tunerstick + Raspberry + 720p ---> Bildqualität akzeptabel (gelegentliche Klötzchenbildung)
TVH + DVB-Tunerstick + x86 + 720p ---> Bildqualität einwandfrei

Erkenntnis 2:
Die Empfangsqualität der Sticks hängt nur geringfügig vom Signalpegel ab. Ich bin mit dem Raspberry an verschiedene Stellen im Haus gewandert, auch direkt an den Hausanschlussverstärker, und konnte nur geringe Veränderungen bei den Artefakten sehen. Natürlich habe ich es auch mit geringeren Pegeln (Dämpfungsglieder) versucht. Der Unterschied, ob der Stick im Raspi oder im x86 steckt, ist SEHR viel größer.

Dann habe ich den HTPC auf v9 0202 aktualisiert. Da ich die Titan-Skin verwende, muss eine Titan Alpha-Version für Kodi v18 installiert werden. Als Backend bleibt zunächst VDR.

Der TV-Empfang mit DVB-Stick funktioniert auf Anhieb, aber nach einigem Umschalten der Kanäle "VDR vnsi client: Channel: no data", permanent auf allen Kanälen. Reboot hilft nicht. Einziger Weg den ich gefunden habe: VDR backend + Client deaktivieren, Reboot, VDR wieder aktivieren. Den Rest des Tages sind dann keine weiteren Fehler mehr aufgetreten, trotz häufigem Umschalten und intensiver Nutzung des Timeshift.

Leider kommt heute beim Booten wieder die gleiche Fehlermeldung...

Ich werde jetzt mal mit TVH bzw. der DD-Karte testen.

Hi CvH,

so werde ich das mal angehen. Muss mich aber erst mal einlesen, wie man mit den v9-Versionen umgeht.

Ich habe übrigens erst jetzt gepeilt, dass der Spezialbuild der 8.0.2 mit den DD-Treibern von DIR kommt! DANKE dafür!

Die aufgetretenen Probleme mit VDR nach ca. 1 Woche Nutzung auf 2 Geräten:

- 5x Aufhängen von KODI beim Umschalten auf ein anderes Programm (davon 1x über die FB-Taste, 4x über Anklicken im EPG). 3x beim HTPC aufgetreten, 2x beim Raspi. Teilweise beim Umschalten aus Timeshift heraus, aber auch aus Live-TV. Alles friert ein, nach einigen Sekunden startet Kodi neu (es erscheint der Krypton-Screen). Welches Logfile sollte ich mir anschauen?

- Einfrieren der Timeshift-Wiedergabe beim Navigieren in der Nähe des Anfangs (also die ältesten Daten), keine erkennbare Reaktion mehr auf Skip-Tasten. Trotzdem bin ich nach einigem Hin- und Herdrücken im Live-Modus gelandet, wo alles wieder funktioniert hat (auch nochmaliges Zurückgehen im Timeshift an die Problemstelle ging dann fehlerfrei). 2x aufgetreten beim Raspi.

- VDR am Raspi mit dem DVB-Stick produziert bei 720p-Kanälen weiterhin grüne Artefakte. Bei SD habe ich noch keine gesehen, 1080i kann ich nicht testen. Ich vermute langsam, dass DVB-C Sticks für HD-Empfang generell nicht sonderlich viel taugen (habe bisher 3 Typen getestet). Beim HTPC mit DD-Karte bisher keinerlei Bildfehler gesehen.

Edit: in den Kodi crashlogs steht im Zusammenhang mit dem ersten Problem (soweit ich das zeitlich noch zuordnen konnte):

HTPC (LE 8.0.2 mit den DD-Treibern)

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000090a1d5 in ?? ()


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000003241290 in ?? ()


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000700335f in ?? ()

Raspi (LE 8.2.1)

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x753fcb9c in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) () from /usr/lib/libstdc++.so.6


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x76f52b64 in memcmp () from /usr/lib/libarmmem.so

Ob der 2. Absturz dieses Problem war kann ich nicht mit Sicherheit sagen.

Mit Skip meint ihr die +/- 10s/30s/1Min... Sprünge?

Wenn die laufende Sendung den Timeshift-Bug von TVH (4.2) nicht auslöst, funktioniert das Springen. Bei aufgewecktem Bug ist neben den Artefakten und dem Ruckeln/Hängen auch das Springen ziemlich daneben.

Bei VDR habe ich beim Springen bisher überhaupt kein Problem beobachtet.

Etwas blöd ist, dass es beim Springen keinen "Anschlag" hinten und vorne gibt. Man kann in Kodi Sprünge von zig Stunden anwählen, egal wie wenig im Puffer steht. Besonders der Übergang in den Livemodus ist schwer zu erkennen.
Die Sprungmarkierung im Fortschrittsbalken täuscht erst mal vor, dass der Sprung möglich ist, aber er wird dann nicht bzw. nur teilweise ausgeführt. Das ist bei MePo meiner Meinung nach besser gelöst.
Scheint ein Kodi-Thema zu sein, da mit TVH und VDR kein Unterschied besteht.

Mit ext4 scheinen die Aufnahmen mit VDR auch bei parallelem Timeshift auf die Platte zu funktionieren! Sogar wenn man während der Aufnahme im Timeshift zurückgeht, also 3 Filezugriffe nebeneinander laufen.

Aber schon das nächste Problem: Es scheint, als reagiert VDR auf DVB-Datenfehler "auffälliger".

Am R-Pi teste ich mit 2 DVB-C-Sticks (Edision Opti-Combo und TT CT2-4400-v2). Das Antennenkabel an meinem Bastelplatz sitzt sehr locker in der Buchse des Sticks, was dann beim Bewegen verständlicherweise Bildfehler produziert, und nicht weiter verdächtig war.
Jetzt nach Umzug an den Verwendungsort, wo die Verkabelung einwandfrei und ohne Kontaktprobleme ist, zeigt VDR immer noch alle paar Minuten Bildfehler (flächig grünes Bild in der unteren Hälfte), während TVH derartiges nicht produziert. Die Fehler landen auch im Timeshift und der Aufnahme. Kein Unterschied zwischen den beiden Sticks, die sind aber wohl auch baugleich.

Beim HTPC mit DD Cine-CT Karte läuft VDR dagegen unauffällig.

Ein Vergleichstest mit dem DVB-C Stick am HTPC klappt leider nicht, dieser wird von VDR bzw. LE offenbar nicht erkannt (die DD-Karte war dabei natürlich ausgebaut). Könnte aber daran liegen, dass ich hier eine Sonderversion von LE mit DD-Treibern verwende

... nicht nur viel zu langsam, sondern auch noch falsch ermittelt

Die richtigen Werte sind:
ntfs Raspi/LE 9,3 MB/s
ntfs HTPC/LE 27 MB/s
ext4 Raspi/LE 14,1 MB/s

Merke: Kopiervorgang auf Remote-System, angestoßen im Dateimanager (Nemo), läuft offenbar über ftp, schaufelt also die Daten 2x über das Netzwerk. Die obigen Daten sind mit cp im SSH-Terminal ermittelt.

Werde jetzt mal schauen, wie sich VDR mit der ext4-Platte verhält.

@d00dl03: Beim Installieren von VDR habe ich mich hier orientiert:
http://blog.helmutkarger.de/raspberry-medi…er-teil-11-vdr/
Und dann die channels.conf zusammengestutzt auf meine Sender. Siehe auch den Link von CvH oben.
Übrigens, mit der Titan-Skin funktioniert der VDR-Config-Dialog nicht. Estuary geht.

Sieht aus als wäre LibreElec nix gut mit NTFS...

Jeweils 1 GB auf der selben USB-Platte in ein anderes Verzeichnis kopiert:
- USB2-Port am Raspi 3, LibreElec: 1,2 MByte/s
- USB2-Port am HTPC, LibreElec: 2,4 MByte/s
- USB2-Port am PC, Linux Mint: 27 MByte/s

Okay, ganz so perfekt ist VDR anscheinend doch nicht.

Zumindest dann nicht mehr auf dem Raspi, nachdem man erkannt hat, dass die ganze Zeit nur auf die SD-Karte geschrieben wurde, und nicht wie gedacht auf die USB-Platte. Bei Aufnahmen während Live-TV (auch ohne im Timeshift zu sein) reicht offenbar die Bandbreite des internen USB-Hub-Flaschenhalses nicht aus, und sowohl Livebild wie auch Aufnahme sind unbrauchbar.

Kann aber eigentlich nicht sein, da der Datenverkehr über USB in der Konfiguration mit THV bzw. VDR genauso groß sein sollte (3 oder 4 ts-Ströme inklusive des DVB-C Sticks, je nachdem ob Timeshift aktiv oder nicht). Hier gab es mit TVH kein erkennbares Problem. VDR scheint die Daten sehr viel ungünstiger zu schreiben/lesen, zumindest für die Verhältnisse am R-Pi. Ein Unterschied, weil die Timeshift-Daten bei VDR in einer einzigen riesigen Datei liegen, statt vielen kleinen Files wie bei TVH?

Auf dem HTPC läuft VDR weiterhin problemlos.

Edit: mir fällt gerade ein, die USB-Platte ist noch NTFS-formatiert. Könnte das für das Handling sehr großer Dateien am R-Pi kritisch sein?