Beiträge von brandtan
-
-
Hi Leute,
ich teste gerade mal die Timeshift-Funktion mit RPI 3 mit LE 12.0.1 & TVH 4.3.2180.
Sehe gerade, dass das Fenster komisch aussieht, wenn ich bei Timeshift die Box anklicke, um es zu aktivieren.
Die Box bleibt dann leer, also nicht angeklickt aber Timshift funktioniert grundlegend.Nur das Fenster sieht "kaputt" aus. Es sieht einfach so aus, als hätte ich da nicht draufgeklickt oder sowas!? Ganz komisch. Total verbuggt.
Falls das bekannt ist, bitte Info, dann ist das halt so.
Screenhot im Anhang.
-
Hi leute,
mein Telersing sagt, dass mein Pi keine Internetverbindung hätte
Bis eben gerade hatte Telerising noch Verbindung zu Zattoo aber jetzt behauptet Telerising, dass es keine Internetverbindung hat
Da man Google anpingen kann via: pin google.de & ping 8.8.8.8 muss ich leider sagen, dass die Aussage falsch ist.
Haben die Chinesen oder Russen wieder Tiefseekabel gekappt oder hat Telerising keine Lust mehr
Wie kann man Telerising sagen, dass es den DNS/Gateway des Pis nimmt?!?!
Verstehe ich nicht...
-
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
-
brandtan 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.
-
Es 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".
Codeffmpeg -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.
-
dann 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
log schalte ich ein und überstelle es sobald der Screensaver noch einmal hängen sollten. 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 EstuasyDas 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.Code
Alles anzeigenroot@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
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 gefundenTja...
was muss da nochmal machen?