Die Meldung kannst du schlichtweg ignorieren.
Ah oaky. Danke
Die Meldung kannst du schlichtweg ignorieren.
Ah oaky. Danke
Hi Leute,
ich habe Telerising vom Jan-Luca Neumann in Betrieb V0.13.4. ARM64 und das ist dann eine Testversion oder so.
Jedenfalls sagt die api bei Start, dass man den WSGI Server nehmen soll.
Was ist das?
LG
Alles anzeigenbrandtan Du solltestest versuchen, herauszufinden, woher die Aussetzer in Deinen Dateien kommen. Es kann sein, das diese Aussetzer gar nicht unvermeidbar sind, sondern auf ein Problem mit Linux und SMB zurückzuführen sind.
Wie genau wurden die Aufnahmen mit den Problemen gemacht:
Auf welchem Linux/Kernel-Version laeuft dein TVH ?
Wurden die Dateien bloss auf lokale Filesystem auf dem TVH geschrieben, oder wurden die auf ein Filesystem geschrieben, was SMB ist und z.b. Platten auf einer NAS sind ?
Und das wäre nur die Fehlerquelle, die HarryH aufgetan hat. Auch andere Fehlerquellen fuer Aussetzer sind häufig vermeidbar.
Außer halt, Dir geht es bloss um alte existierende Aufnahmen, aber so hat sich das bei Dir für mich nicht angehört...
Ich weiß nicht wer es zuerst schrieb aber die Sache mit über das Netzwerk aufnehmen muss es sein. Da ich vorher immer die jeweiligen Platten via Aktiv-USB-Hub direkt am HUB dran hatte, denke ich ist das auf jedenfall der erste Ansatz und ja es ist bestimmt auch der Kernel, da der TVHEad auf dem LE10.0.4 läuft. Der Kernel ist bestimmt nicht der Neuste. Ich weiß gerade nicht welche Version das ist.
Aber das hat mir bereits geholfen und ich würde sagen, Thema erledigt zunächst.
Alles anzeigenEs gibt eine fiese Regression im Linux Kernel das CIFS-Modul betreffend:
https://lore.kernel.org/linux-cifs/DFC…7882@gmail.com/
Ich vermute Du hast ein aktuelles LE im Einsatz und damit einen 6.6er Kernel oder ggf. eine andere betroffene Kernel Version > 6.2.16 und < 6.10.9. Das dort beschriebene Phänomen ist nicht auf die ARM-Plattform (RPi) beschränkt, sondern nur zufällig die Testplattform. Auf meinem Desktop-System konnte ich ein ähnlich gelagertes Verhalten nachstellen, bevor ich den Eintrag aus dieser Mail-Liste gefunden habe. Keine Angst, gibt noch mehr davon. https://lore.kernel.org/linux-cifs/9bc…p.fastmail.com/
Bei mir sorgte dieser Bug für ca. 1 halbes Jahr lang für korrupte Downloads mehrerer ca. 2GiB Firmware-ZIPs (Offline-Update) für unseren Fernseher beim direkten Speichern auf das NAS via SMB-Mount. Lokales Speichern und nachträgliches Kopieren mit cp oder mv hat den Fehler nie nachvollziehbar getriggert. Diese Downloads (Rechner- und Browser-unabhängig) allerdings schon. Der gleiche Download via Windows durchgeführt war wiederholbar fehlerfrei. Testdownloads mit anderen großen Dateien wie ISOs waren nicht geeignet um es regelmäßig zu provozieren.
Also bevor sich Meldungen häufen: "Habe es gerade probiert, bei mir geht es ohne Probleme." Reicht nicht als Testcase.
Wen es interessiert was in den Dateien verändert war: Die korrupten Stellen in den ZIP-Files waren an unterschiedlichen Stellen immer durch 0x00 Bereiche ersetzt. Bei jedem Downloadversuch an anderen Stellen. Für einen TS-Stream ist sowas natürlich Gift.
In meinem Fall mit 6.5 und 6.8 Kernel hatte ich mir einen Workaround erarbeitet. Den Cache für das Mount abschalten. Das kannst Du ja mal probieren und in Deinen Mount-Optionen unterbringen "cache=none". Wenn Du diesen Mountpoint nur zum Herausschreiben der Aufnahmen verwendest, sollte der Performanceverlust nicht ganz so ins Gewicht fallen. Beim Auflisten von großen Verzeichnisstrukturen mit vielen Ordner/Dateien ist es allerdings spürbar.
Auf meinem Desktop bin ich auf Kernel 6.11. gewechselt, seitdem komme ich wieder ohne diesen Workaround aus. Daher meine Annahme, es handelt sich um die selben Bugs die James Young und Zack Weinberg dort ausführlich beschreiben.
NFS ist auch nicht zwingend fehlerfrei, könnte aber dieses SMB-Problem umschiffen. Ob eine schnelle SD-Karte mit genügend Kapazität für mindestens 2 Aufnahmen auf einem RPi3 für eine Gegenprobe ohne File-Share schnell genug angebunden ist, kann ich gerade nicht einschätzen ...
Ich weiß nicht was ich darauf antworten soll, weil ich nicht mehr weiß worum es hier geht.
omg da hat mein Hirn aber Blödsinn verzapft! Ich meinte AVI Demux - damit kann man die Aufnahmen schneiden oder auch einfach speichern und dann funzt das Spulen wieder.
Ah okay. ich habe eben das Toll getestet aber AVIDEMUX meldet mir "Video zu kurz" & "ungültige Zeitstempel" und bricht dann ab.
Denke, dass das nicht die Lösung ist.
Meine ts-Aufnahmen sind ja nicht nur "nicht zurückspulbar" sondern auch dazu noch kaputt, wie man im aus den Logauszügen da oben sehen kann.
HarryH Ich habe kein DVB, sondern IPTV. Mein LibreElec Raspi3 mit TVHeadend mounted via SMB ein NAS und speichert dort.
Der VLC-Player sollte als Ballermännchen alles rausballern, was da reingeschmissen wird. Meiner Meinung nach ist der VLC Player da einfach am kompatibelsten. Andere Infos aber gerne gesehen!
Übrigens: Meinen Beobachtungen zu folgen passiert das mit den nicht spulbaren aufnahmen immer dann, wenn sich Aufnahmen zeitlich überschneiden und/oder parallel laufen.
Wie gesagt ist das aber nicht wichtig. Ab heute habe ich auf MKV umgestellt. Mal sehen.
Okay, erstmal: Guter Input von allen!
Ich bin kommerziellen Lösungen gegenüber aufgeschlossen und würde eine Lösung kaufen, wenn die das macht, was sie soll.
Ich habe MKVToolNix auf meinem Rechner und wusste nicht, dass das damit auch geht? Ich nutze MKV-ToolNix zum beschneiden der AUfnahmen.
Wie soll das mit MKVToolnix gehen?
###### Edit #######
Dieses Problem bei TVH zu lösen sollten man nicht tun. Wenn man weiß, dass pass nicht gut funktioniert, einfach nicht nutzen und das nutzen, was funktioniert.
Ich habe also erstmal mkv eingestellt oder was schlagt ihr vor?
Hi Leute,
wenn man mit pass bei dem TVH aufnimmt, kann es ja vorkommen, dass man nicht vorspulen kann usw.
Das ist ja eine bekannte Sache.
Jedenfalls frage ich mich, ob man diese ts Aufnahme nicht mit ffmpeg heilen kann.
Das habe ich einmal mit ffmpeg versucht aber da werden dann teile des Films rausgeschnitten?! Der Film ansich ist dann aber vorspulbar.
Hier mal ein Beispiel Film von vorhin. Sehe da im ffmpeg-Log Output viele "timestamp discontinuity" & "Packet corrupt".
ffmpeg -i Desktop/Mega-krasser-Film.ts -codec copy Desktop/Mega-krasser-Film.mkv
[mpegts @ 0x7fe807f06000] Packet corrupt (stream = 2, dts = 13660200).=7286.4kbits/s speed= 449x
timestamp discontinuity (stream id=258): -129600000, new offset= 5247424000
[aist#0:1/eac3 @ 0x7fe807f08940] timestamp discontinuity (stream id=257): 129632000, new offset= 5117792000
[aist#0:1/eac3 @ 0x7fe807f08940] timestamp discontinuity (stream id=257): -129568000, new offset= 5247360000
Frage ist:
Wie kann ich am einfachsten die "kaputte" ts Aufnahme heilen usw..
Aufnahmen brechen ab wenn:
1) Kein Speicherplatz mehr vorhanden
2) Falsches Dateiformat. Es muss heutzutage NTFS oder auch ExFat sein.
3) Wenn man im TVHead-Server die Aufnahme stoppt
4) Falls man einen Auto-Neustart via Cronjob erstellt haben sollte
passcht schooo ...
logik ?
wenn du den screensaver abschaltest, wird der wohl kaum hängen bleiben können ... (ich klugscheixx wieder, I know ...)
So, nachdem ich den screensaver deaktiviert habe, sieht es besser aus. Funktion von Kodi ist wieder gegeben.
Der Screensaver hat dann wohl ein Problem bei mir und andere Dienste blockiert.
Nach Abschaltung des Screensavers gibt es derzeit keine Probleme mehr.
Da ich den Screensaver auch nicht zwingend benötige, lasse ich das Ding abgeschaltet.
Thread solved.
Alles anzeigendann ist das Teil auch nicht abgestürzt, eher nur Teile davon (sach ich ma so, nach kurzen Überflug durch deine logs, wo *ich* auf die Schnelle so nix erkennen kann)
Für mich ist es ein Absturz, wenn ich die Kiste nur noch via Stecker ziehen wieder in Schwung bringen kann
kill -9 schiesst den Prozess auch nur ab; restartet wird da nix !
und wenn schon, dann:
kill -9 $(pidof kodi.sh)
*und* [1]
kill -9 $(pidof kodi.bin)
oder nur
kill -9 $(pidof kodi.bin)
[1] proof nach "kill -9 $(pidof kodi.sh) "mit "ps aux | grep kodi"
=> die kodi.bin lofft noch, weil die durch die kodi.sh gestartet (?) wurde
und da die *.sh caller von *.bin ist (?), reicht "kill -9 $(pidof kodi.bin) aus um sowohl die *.bin, als auch die *.sh zu beenden
zumindest hier auf einem PC.
noch was:
"$pidof_kodi.sh" ist eine Variable mit Namen "pidof_kodi.sh"
"$(pidof kodi.sh)" ist auch eine Variable, deren Inhalt aber dynamisch mit der Ausgabe eines Befehls (alles zwischen den Klammern) gefüllt wird
===
anyway, ich denke nicht das es auf PI's anders ist als auf PC's (x86 Architekturen) und denke, dass es per systemctl gehen müsste.
also kodi restart mit:
systemctl restart kodi.service
===
bzgl. KODI_CRASH.log
fällt mir nur ein, dass der crash log beim graphischen updaten von LE erzeugt wird. manuelle Updates erzeugen keinen crash log
. Bug ist gemeldet, aber nicht gefixed dein crash log
sieht zumindest ähnlich aus, sodass es der graph. update bug sein könnte. Proof:
- crash log
löschen - ssh login
- cd .update
- curl <LE-Update.img>
- reboot
crash log
da ? - update via graph. Oberfläche
crash log
da ? ===
du solltest auf jeden Fall debug einschalten !
z.B.:
debug log
ein via advancedsettings .xml mit Inhalt:
<advancedsettings version="1.0">
<loglevel hide="false">1</loglevel>
</advancedsettings>
Achtung:
wenn du schon eine advancedsettings
.xml unter "/storage/.kodi/userdata" hast, musst du die sichern und/oder ggf. ergänzen
joe:
Sehr ausführlich, super aber lass uns schauen, dass wir die Ursache des Absturzes investigieren.
Ja, das Debug
Da kch erstmal nur vom Screensaver sprach, habe ich den einmal abgeschaltet, ohne die AdvanceSettings edititiert zu ahben und schaue was passiert.
Der Raspi ist bei mir immer an, auch wenn der TV aus ist.
Übrigens habe ich gesehen, dass die Nutzung des RAMS nach Neustart von 40% sehr schnell auf 80% erhöht.
Das behalte ich im Auge.
s Hi Leute,
auf meinem Raspi 3 und dem aktuellen LibreElec mit Kodi Nexus, stürzt das Ding in einer Tour ab.
Fehler ist:
Der digital clock Bildschirmschoner friert ein. Keine Möglichkeit via Bluetooth Fernbedienung das Ding zu bedienen/rebooten o.ä. Ich kann aber mit der Kodi Remote auf dem iPhone Befehle senden, die aber nicht ausgeführt werden: Reboot z.B.
Der Zugriff via SSH funktioniert. Keine Möglichkeit aber via kill -9 $pidof_kodi.sh Kodi neu zu starten. Es geht aber reboot auf terminal Ebene.
Was könnte das denn sein.
Der Fehler besteht schon sehr lange. Ich ziehe immer einmal am Tag den Stromstecker, um Kodi neu zu starten und das Problem zu beseitigen.
Log habe ich auch angehängt.
So liebe Rätselfreunde ders OpenSource Medien Centers!
Die jugendforscht Rätselstunde ist eröffnet:
Was ist der Unterschied zwischen dem Voraufnahmepolster bei Kodi und dem Voraufnahmepolster im TVhead?
..... uuuunnnnddd bitte
Das UpNext Addon funktioniert nachweislich nicht unter der Standard-Visualisierung Estuasy:
Gestestet mit:
Raspi 3 mit LibreElec 11.0.6 Estuasy
Das UpNext Addon funktioniert aber mit Estuasy Mod V2 ohne Probleme.
Dort ist auch eine native Integration hinterlegt.
Hi Leute,
in diesem Thread geht es mal wieder weiter und ich habe Neuigkeiten dazu.
Ich nutze gerade einen Raspi 3 mit Debian Bullseye und Linux tvhead2024 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
Ich sehe, dass einfach die Auslastung eben mit dem Aufruf von /lib/systemd/system/tvheadend.service -f -u root -g video $OPTIONS
Bei 65% bis 85% lag.
root@tvhead2024:~# systemctl stop tvheadend.service
Warning: The unit file, source configuration file or drop-ins of tvheadend.service changed on disk. Run 'systemctl daemon-reload' to reload units.
top - 20:23:41 up 11 min, 1 user, load average: 7,31, 5,65, 3,35
Tasks: 159 total, 12 running, 147 sleeping, 0 stopped, 0 zombie
%CPU(s): 63,5 us, 12,2 sy, 0,0 ni, 4,8 id, 0,0 wa, 0,0 hi, 19,4 si, 0,0 st
MiB Spch: 959,5 total, 104,4 free, 528,3 used, 326,8 buff/cache
MiB Swap: 100,0 total, 100,0 free, 0,0 used. 413,0 avail Spch
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
1425 root 20 0 215792 61536 35532 S 31,5 6,3 0:03.84 ffmpeg
1289 root 20 0 2266372 114684 11976 S 31,2 11,7 0:21.59 tvheadend
1417 root 20 0 215384 61036 35640 S 27,9 6,2 0:04.42 ffmpeg
1424 root 20 0 215412 61012 35576 R 27,9 6,2 0:03.93 ffmpeg
1426 root 20 0 215248 60996 35760 S 27,3 6,2 0:03.92 ffmpeg
1429 root 20 0 216564 62792 35876 R 26,6 6,4 0:03.86 ffmpeg
1436 root 20 0 216048 61888 35548 R 26,3 6,3 0:02.98 ffmpeg
1428 root 20 0 216508 62844 35892 R 26,0 6,4 0:03.94 ffmpeg
1416 root 20 0 215364 60812 35360 R 25,0 6,2 0:04.74 ffmpeg
1330 root 20 0 215384 60804 35388 R 24,4 6,2 0:21.10 ffmpeg
1423 root 20 0 215328 60912 35532 R 24,4 6,2 0:03.90 ffmpeg
1415 root 20 0 0 0 0 R 24,0 0,0 0:04.34 ffmpeg
20 root 20 0 0 0 0 S 6,2 0,0 0:07.22 ksoftirqd/1
14 root 20 0 0 0 0 S 5,5 0,0 0:07.34 ksoftirqd/0
30 root 20 0 0 0 0 S 5,5 0,0 0:06.99 ksoftirqd/3
25 root 20 0 0 0 0 S 4,5 0,0 0:07.28 ksoftirqd/2
42 root 20 0 0 0 0 S 2,9 0,0 0:16.22 kcompactd0
1427 root 20 0 10080 3512 2884 R 1,9 0,4 0:00.53 top
1437 root 20 0 51548 3616 3168 R 1,9 0,4 0:00.06 ffmpeg
15 root 20 0 0 0 0 R 1,3 0,0 0:04.99 rcu_preempt
55 root 20 0 0 0 0 S 0,6 0,0 0:00.39 kswapd0
Alles anzeigen
Zudem war es so, dass es einige ffmpeg pids gab:
Ich habe einmal das -f rausgenommen. Weiß nicht genau was es macht aber irgendwelche Ableger oder so des TVHead brauche ich nicht.
Jetzt, wenn nur /lib/systemd/system/tvheadend.service -u root -g video $OPTIONS aufgerufen wird, ist die Systemlast des Raspis bei 12,5 wenn da eine Subscription stattfindet.
Ich müsste irgendwie die Systemlast runter bekommen?
Hat da jemand Ideen?
Das kann ja mehrere Gründe haben.
Hast du das Problem auch in Richtung anderer Clients?
Moin, das teste das bereits aber bisher meine ich nur bei dem Raspi3 mit LE 11.6. das Zwischenspeicherproblem zu haben.
Die arm64-Variante ist vermutlich korrekt für das 64bit-System.
stimmt..
Hi Leute,
wie bringt man Telerising nochmal zum Laufen? Kann mich nicht mehr erinneren, wie das geht.
Habe telerising-v0.11.6_armhf_raspbian.zip auf meinem Raspi geladen und weäre bereit das Ding zu starten aber wenn ich ./api im Verzeichnis eintippe, um es zu starten, kommt nur die FGehlermeldung: -bash: ./api: Datei oder Verzeichnis nicht gefunden
Tja...
was muss da nochmal machen?
Tja, ein Problem, welches mal damals bei den älteren Versionen vorkam: Zwischenspreicherung.
Mein Raspi 3 ist per LAN Kabel angeschlossen. Trotzdem leider immer mal wieder, vier oder auch fünf mal hintereinander Zwischenspeicherung auf dem Bildschirm zu sehen
Der Raspi3 ist ein TVH-Client.
Der TVH bekommt über Telerising den Stream via ffmpeg Pipe.
Ist die Ursache für das Zwischenspeichern bekannt?
Abschließend nochmal die Info, dass man dann auch ein System-Dienst erstellen sollte.
1) touch /lib/systemd/system/easyepg.service
2) Inhalt:
-> ich habe die ZIP-Datei entpackt und dann umbenannt.
Liegt nun unter /media/link/easyepg-lite-main
easyepg.service [Unit]
Description=Powerful EPG Grabber for headless use cases.
After=multi-user.target
[Service]
Type=simple
WorkingDirectory=/media/link/easyepg-lite-main/
ExecStart=/usr/bin/python3 /media/link/easyepg-lite-main/main.py
Restart=always
[Install]
WantedBy=multi-user.target
Alles anzeigen
3) Dann haut man noch diesen Befehl hinterher:
systemctl daemon-reload && systemctl enable easyepg.service
Das bedeutet, dass die Systemdeamons neu geladen werden und falls das erfolgreich ist, wird der easyepg.servcice dann auch aktiv geschaltet.Aber man muss den Dienst auch noch starten, wenn man nicht einen Reboot macht.
Letzter Schritt:
4) systemctl start easyepg.service
Immer professnionel sehen. Es ist kein persönlicher Angriff.
Ich betrachte das hier von aussen. Versetz dich in die Lage desjeniegen, der deine Programme benutzen soll.
Die Lösung für alle anderen auf Raspian wäre dann:
1) Die ZIP-Datei laden und auf den Pi bringen, Wie auch immer man das machen mag.
2) Entpacken der Datei. Ich habe das dann noch via "mv" unbenannt. Der Einfachheit halber.
3) Die Voraussetzungen installieren:
3.a) apt-get install pip python3
3.b) python3 -m pip install bottle requests xmltodict
Dann wird es starten.