[live] Weiterentwicklung v3.3.x

  • Verwende Live-Version: 3.3.7 - aus Zabrimus GIT.


    VDRSternELEC auf Odroid N2+ Hardware


    Mir werden seit dem heutigen Update keine Aufnahmen mehr angezeigt:

    Browsercache habe ich gelöscht. Im VDR OSD sind Aufnahmen da und werden auch abgespielt.


    Was könnte da falsch laufen?

    Edited once, last by vdr_rossi ().

  • Was könnte da falsch laufen?

    Ich habe jetzt mal ohne tvscraper mit chrome getestet, funktioniert perfekt.

    Falls das direkt nach dem Start von VDR passiert: einfach mal 1 Minute (mindestens) warten, und Browser refresh drücken.

    Wenn das nicht hilft, brauche ich mehr Infos:

    • Syslog
    • Seiten-Quelltext (im Browser)
    • Ruf doch mal den Debugger im Browser auf (shift+Strg+I), und prüfe, ob Fehler angezeigt werden.

    ~ Markus


    P.S.: Könnte ein Fehler beim Escapen von Sonderzeichen im Namen/Titel der Aufnahme sein

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Beim Einlesen umfangreicher Videotheken kann das schon etwas länger dauern. Ich hatte auch schon beobachtet, dass, wenn man zu früh auf die Aufnahmen zugreift, sich der Webserver "verklemmen" kann. Im Log finden sich dort immer wieder ca. 15 Sekunden lange Versuche des Recording Managers, die Videos einzulesen:

    Quote

    Oct 15 17:22:29 HTPC vdr: [1194] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time: 15.89477

    Oct 15 17:22:46 HTPC vdr: [1194] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time: 16.81296

    Oct 15 17:23:02 HTPC vdr: [1194] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time: 16.80956

    Oct 15 17:23:19 HTPC vdr: [1194] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time: 16.87286

    Oct 15 17:23:36 HTPC vdr: [1194] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time: 16.72845

    In diesem Stadium hat bei mir meist nur ein Reboot geholfen; deshalb bis zum ersten Zugriff also lieber solange warten, bis der VDR mit dem Initial-Scan durch ist. Ansonsten habe ich mit der neuen Version keine Probleme beobachtet.


    Ich habe auch einmal alle kritischen Sonderzeichen synthetisch in Namen, Titel, Untertitel und Beschreibung eingefügt:



    … und keine Probleme damit beobachten können. Schon gar nicht mit Umlauten und dergleichen.


    MarkusE , vielleicht sollten wir nach den ganzen Modifikationen die Versionsnummer wieder einmal hochzählen, damit die Bezugnahme leichter fällt. Wie wäre es denn mit v3.4.0 oder gar v4.0.0? ;)

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited once, last by SHofmann ().

  • Mir werden seit dem heutigen Update keine Aufnahmen mehr angezeigt:

    Ich kann das bestätigen.

    Bei mir geht "Programm" auch nicht, Zeitleiste funktioniert aber z.B.

    Bei den Aufnahmen geht Serien und Filmsammlungen zum Teil (hier wird nur die Struktur, aber nicht die Aufnahme selbst angezeigt), aber nicht Dateisystem und Aufnahmen /flach).


    Den Cache habe ich zwischenzeitlich auch mal gelöscht und den VDR neu gestartet. Auch andere Browser versucht.

    Das Einlesen der Aufnahmen sollte auch kein Problem sein, das geht trotz der Menge recht schnell. Im VDR-Aufzeichnungsmenü sind alle Aufzeichnungen vorhanden.


    Folgende Meldung kommt einmal beim Aufruf von Live im Log:

    Code
    vdr[2460]: [4933] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time:   1,46778

    Folgende Logeinträge wenn ich in Live auf Aufnahmen klicke:

    Code
    Okt 24 15:16:36 vdr[2460]: [4931] live, time recordings.ecpp recs lv 0: 0,000000
    Okt 24 15:16:36 vdr[2460]: [4931] live, time recordings.ecpp recs lv 0: 0,000000
    Okt 24 15:16:36 vdr[2460]: [4931] live, time recordings.ecpp recs lv 0: 0,000000
    Okt 24 15:16:36 vdr[2460]: [4931] live, time recordings.ecpp recs lv 0: 0,000000
    Okt 24 15:16:36 vdr[2460]: [4931] live, time recordings.ecpp: 0,026586

    Das Ganze ist in älteren Versionen schon mal gegangen.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich habe Live gerade nochmals frisch aus dem Git gebaut:



    … und kann nach wie vor keine Probleme beobachten. Da wir ja alle unterschiedliche Environments haben, etwa Ubuntu 22.04.1, Fedora 40 usw., könnten da eventuell die verschiedenen Versionen der eingebundenen Komponenten – insbes. TNTnet – einen Einfluss darauf haben, ob es flutscht oder ob Probleme auftreten?


    PS: Beachtet bitte, dass ich Live zwar mit StreamDev und EPGsearch, aber ohne den TVscraper nutze.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Hast du mal den Browsercache gelöscht`?

  • Ja, hatte ich auch schon mal.

    Auch mit verschiedenen Browsern, gleiches Verhalten.


    Wenn ich mal Zeit habe, kann ich auch mal ein git bisect machen um zu sehen, seit wann es bei mir nicht mehr geht...


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich nutze tntnet 3.0.

    Bei mir scheint es tntnet 2.2.1 zu sein:

    Quote

    libtntnet-dev/jammy,now 2.2.1-4build2 amd64

    Ich hoffe doch nicht, dass sich die beiden Versionen so gravierend im Verhalten unterscheiden, dass dies ausschlaggebend für die Probleme wäre… :/

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Das Problem kann mit der letzten Version von VDR*ELEC nachvollziehen. tvscraper habe ich nicht gestartet.


    Mit dem letzten Commit vom 22.10 (recordings refresh rate limit, url escape) kann ich die Aufnahmen nicht sehen. Mit dem Commit davor vom 20.10 (Fixes for authenticated requests and HTML line breaks) als einzige Änderung beim Build funktioniert es einwandfrei.


    Der Verdacht liegt schon nahe, daß beim letzten Commit etwas nicht richtig funktioniert.

    In VDR*ELEC werde ich ich einen Downgrade von Live machen.

  • Der Verdacht liegt schon nahe, daß beim letzten Commit etwas nicht richtig funktioniert.

    Das kann ich bestätigen. Ohne den letzten commit gehen die Aufnahmen wieder.

    Was bei mir damit immer noch nicht geht, ist "Programm".


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Im git ist ein Update. Bitte testen.


    Ich denke, es liegt am Encoden von speziellen Zeichen. tntnet 3* steigt da schneller aus als tntnet 2*.

    Und manche Anwender haben halt noch Aufzeichnungen, in denen "kritische" Zeichen vorkommen. Andere nicht. Daher tritt der Fehler nicht bei allen auf.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Im git ist ein Update. Bitte testen.

    Das war es leider nicht. Mit der letzten Version habe ich weder "Aufnahmen" noch "Programm" :(


    In "Aufnahmen" sehe ich im Log nur

    Code
    Okt 24 18:00:20 odroid1 vdr[4400]: [4500] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time:   0,03814
    Okt 24 18:00:20 odroid1 vdr[4400]: [4500] live, time recordings.ecpp recs lv 0: 0,375011
    Okt 24 18:00:20 odroid1 vdr[4400]: [4500] live, time recordings.ecpp: 0,556178


    Für "Programm" entsteht kein neuer Eintrag im Log.

  • Ab commit b7cced0c "Recording actions" vom 02.10.2024 geht bei mir "Programme" nicht mehr.


    Vielleicht hilft das bei der Analyse.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Könnt ihr bei euch im Browser bitte auch checken (bei Firefox per "Inspect"), ob Fehler beim Laden der Seiten gemeldet werden? Das hat mich damals zum Problem geführt, das kamel5 genannt hat:

    Ab commit b7cced0c "Recording actions" vom 02.10.2024 geht bei mir "Programme" nicht mehr.

    Markus hat das aber inzwischen mit dem Commit 83a3b9d "dahinter" am 5.10. eigentlich gefixt…

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Markus hat das aber inzwischen mit dem Commit 83a3b9d "dahinter" am 5.10. eigentlich gefixt…

    Hmm.

    Könnt ihr bei euch im Browser bitte auch checken (bei Firefox per "Inspect"), ob Fehler beim Laden der Seiten gemeldet werden?

    Wenn ich bei Aufnahmen auf Dateisystem klicke, kommt das hier:

    Code
    Uncaught (in promise) ReferenceError: addEncodeHtml is not defined                    js.html:208:3
        addEventRec http://192.168.0.5:8008/js.html:208
        addEventRec_r http://192.168.0.5:8008/recordings.html?flat=false&filter=:78
        RecordingsSt_int http://192.168.0.5:8008/js.html:264
        RecordingsSt_a http://192.168.0.5:8008/js.html:174
        rec_string_d_a http://192.168.0.5:8008/js/live/createHtml.js:310
        Toggle http://192.168.0.5:8008/js/live/treeview.js:60
        onclick http://192.168.0.5:8008/recordings.html?flat=false&filter=:1

    Wenn ich auf Programme klicke, bekomme ich das:

    Code
    Uncaught ReferenceError: addEventListString is not defined                     schedule.html:764:16
        <anonymous> http://192.168.0.5:8008/schedule.html:76


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Genau wie kamel5 erhalte ich bei "Aufnahmen"

    Und bei "Programm"

    Code
    Uncaught ReferenceError: addEncodeHtml is not defined
        addEventRec http://odroid1:8008/js.html:202
        addEvent http://odroid1:8008/js.html:105
        addEventList http://odroid1:8008/js/live/createHtml.js:274
        addEventListString http://odroid1:8008/js/live/createHtml.js:294
        <anonymous> http://odroid1:8008/schedule.html:1124

    addEncodeHTML ist eine Gemeinsamkeit.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!