Beiträge von gggggg

    Und dann hat gerade der hourly cron eine Verkettung bis zum crash ausgelöst (Output derzeit softhdvapi):

    Danke das schaut schon besser aus aber:

    Code
    Mar 14 18:59:44 BM2LTS-N64native-MCLI Plex Media Server[1023]: PMS: failure detected. Read/write access is required for path: /var/lib/plexmediaserver/Library/Application Support/Plex Media Server
    Mar 14 18:59:44 BM2LTS-N64native-MCLI systemd[1]: plexmediaserver.service: Main process exited, code=exited, status=1/FAILURE

    wie gesagt hab ich die 2 Verz. inkl -a also mit den Rechten kopiert


    /media/hd/plexmediaserver gehört root mit 755

    /media/hd/plexmediaserver/Library/Application Support und Alles darunter gehört plex mit 755


    Kann es sein dass auch der symlink auch erneuert gehört ? Der Symlink sagt root 777

    /usr/lib/plexmediaserver/Plex Media Server


    Der Symlink verweist auf

    Alles unterhalb /media/hd/plexmediaserver/Library/Application Support/Plex Media Server gehört auch plex.

    1 Dann probier mal 3-5x hintereinander

    - einen Film starten und mit der Stop Taste zurück zum LiveTV ... irgendwann crasht der vdr


    2 wenn man so wie ich E/AC3 downmix für Dolby braucht ist die Lautstärke viiieeel zu leise und wenn du dann zum LiveTV zurück gehst schreckt der Nachbar aus dem Bett auf ;)


    3 mit softhddrm läuft der Softwaredekoder und die GPU bleibt ungenutzt

    weil mir das gerade in der .32 beim Starten untergekommen ist:


    1 Ist das "not found" der soft... normal ?

    2 und softhdvaapi doch vaapi u nicht vapi geschrieben wird ...

    Mar 14 16:02:56 BM2LTS-N64native-MCLI vdr[1570]: 550 Plugin "softhdvapi" not found (use PLUG for a list of plugins)

    Hallo, folgendes Prob.: softhdvaapi (3.3.1-BM2LTS)


    Beim runter fahren stoppt softhdvaapi nicht und es dauert ca. 1:20 bis der vdr es killt ...


    Woher vermutest du, kommt diese Verzögerung ... soll ich das bei softhdvaapi posten ?

    Code
    Mar 14 14:46:00 BM2LTS-N64native-MCLI vdr: [5416] device 6 section handler thread ended (pid=5404, tid=5416)
    Mar 14 14:46:01 BM2LTS-N64native-MCLI vdr: [5417] device 7 section handler thread ended (pid=5404, tid=5417)
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5418] device 8 section handler thread ended (pid=5404, tid=5418)
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: epgsearch
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: systeminfo
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: softhdvaapi
    Mar 14 14:47:23 BM2LTS-N64native-MCLI systemd[1]: vdr.service: State 'stop-sigterm' timed out. Killing.

    OK, dann lade ich mal die .34. ... Danke dafür !


    Beim runter fahren stoppt softhdvaapi nicht und es dauert ca. 1:20 bis der vdr es killt ...


    Woher vermutest du, kommt diese Verzögerung ... soll ich das bei softhdvaapi posten ?

    Code
    Mar 14 14:46:00 BM2LTS-N64native-MCLI vdr: [5416] device 6 section handler thread ended (pid=5404, tid=5416)
    Mar 14 14:46:01 BM2LTS-N64native-MCLI vdr: [5417] device 7 section handler thread ended (pid=5404, tid=5417)
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5418] device 8 section handler thread ended (pid=5404, tid=5418)
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: epgsearch
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: systeminfo
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: softhdvaapi
    Mar 14 14:47:23 BM2LTS-N64native-MCLI systemd[1]: vdr.service: State 'stop-sigterm' timed out. Killing.

    Dann wolle ich noch sagen, dass ich plexmedia und plexmediaserver nochmal frisch von der factory nvssd auf meine HDD (die unter media/hd/export mounted ist) kopiert habe:

    cp -a /media/hd/plexmedia /media/hd/export


    Trotzdem zeigt Plex auch in der .32 die gleiche Meldung :(

    Mar 14 15:59:37 BM2LTS-N64native-MCLI Plex Media Server[1010]: /bin/mkdir: das Verzeichnis »/var/lib/plexmediaserver“ kann nicht angelegt werden: Keine Berechtigung

    Wenn ich live aufrufe stürzt der vdr ab:

    Code
    Mar 14 15:05:07 BM2LTS-N64native-MCLI lighttpd[9012]: /etc/reelhttp-base/cgi-bin/reelhttp.sh: 134: [: -eq: unexpected operator
    Mar 14 15:05:07 BM2LTS-N64native-MCLI kernel: [ 2592.209393] traps: vdr[8987] general protection fault ip:7f034d6352b3 sp:7f03037f95e8 error:0 in libstdc++.so.6.0.28[7f034d609000+f0000]
    Mar 14 15:05:07 BM2LTS-N64native-MCLI systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV


    Noch was: Beim runter fahren stoppt softhdvaapi nicht und es dauert ca. 1:20 bis der vdr es killt ...

    Code
    Mar 14 14:46:00 BM2LTS-N64native-MCLI vdr: [5416] device 6 section handler thread ended (pid=5404, tid=5416)
    Mar 14 14:46:01 BM2LTS-N64native-MCLI vdr: [5417] device 7 section handler thread ended (pid=5404, tid=5417)
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5418] device 8 section handler thread ended (pid=5404, tid=5418)
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: epgsearch
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: systeminfo
    Mar 14 14:46:02 BM2LTS-N64native-MCLI vdr: [5404] deleting plugin: softhdvaapi
    Mar 14 14:47:23 BM2LTS-N64native-MCLI systemd[1]: vdr.service: State 'stop-sigterm' timed out. Killing.

    cinfo ... interesting ... when using vaapi device no crashes when stopping the video ...


    @inj ... regarding the volume prob ... is there a workaround like setting the initial volume when calling mpv ?

    (but I dont think so as it should restore after leaving playback/mpv)

    -v gpu

    -h auto or -h vaapi

    works, but video seems not to be as crisp ... could this be possible ?


    and of course the volume problem persists :( ;)

    Mar 14 13:49:39 BM2LTS-N64native-MCLI vdr: [1647] [mpv]: OSD format not supported. Disabling OSD.#012

    Mit softhddrm ist die CPU laut top bei 17%


    Dann habe ich die mpv.conf gändert und softhdvaapi aktiviert:

    Code
    -v vaapi
    -h auto
    -a alsa/hdmi:CARD=PCH,DEV=0
    -b /media/hd/video
    -r


    Die CPU läuft dann mit <5% aber leider KEIN OSD ... (-h vaapi hab ich auch versucht)

    Hallo, ich nutze BM2LTS mit mcli...


    Es ist egal wie der conflict check angestossen wird. Hier hatte ich einen Timer programmiert.


    Hier das setup:

    hier der syslog Auszug:

    095n5 vdr5cinfo MTD=ein, logs wie immer


    HelmutB !!!DANKE!!!

    0314b x00df, orf2>orf1, mit osdtxt, epgsearch ... schaut wieder gut aus ;)


    0314c x40df, orf2>orf1, mit osdtxt, epgsearch ... OK

    0314d x40df, orf2>orf1, NO osdtxt, epgsearch ... OK


    0314e x40df, sixx>orf2, NO osdtxt, epgsearch ... OK

    0314f x40df, sixx>orf2, mit osdtxt, epgsearch ... OK


    0314g x00df, sixx>orf2, mit osdtxt, epgsearch ... OK


    0314h x00df, sixx>orf2, mit osdtxt, epgsearch, crash wegen timer conflict check.

    1 Ich denke der vdr crashed bei jedem Aufruf von conflict check ... egal ob beim Start od. nach einer Timerprogrammierung. Aber verm. hängt es schon mit der BM2LTS/mcli Kombi zusammen.


    2 60-mcli.conf

    sind wir sicher dass mcli erst nach Allen anderen Plugins staten soll oder macht das bei Plugins wie epgsearch u osdteletext eher Probs? Ich hätte es eher vorab starten lassen ..40- ?!


    3 Welche Kombi soll ich noch testen ?


    4 Was sollen wir "im Alltag" als debug_mask einstellen bzw. welche Methode hast du nun als default (ohne mask) ?

    095n5


    Danke HelmutB . Welche debug mask soll ich testen ... df u 40df ?


    0314a Der vdr crasht ... ev. liegt es an deinem build ?!


    Code
    Mar 14 09:00:35 BM2LTS-N64native-MCLI vdr[1093]: /usr/sbin/vdr: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
    Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/echo-udp [file=/etc/xinetd.d/echo-udp] [line=26]
    Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/servers [file=/etc/xinetd.d/servers] [line=14]
    Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=13]
    Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=13]
    Mar 14 09:00:35 BM2LTS-N64native-MCLI systemd[1]: vdr.service: Main process exited, code=exited, status=127/n/a
    Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=28]
    Mar 14 09:00:35 BM2LTS-N64native-MCLI systemd[1]: vdr.service: Failed with result 'exit-code'.
    Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: 2.3.15.3 started with libwrap loadavg labeled-networking options compiled in.
    Mar 14 09:00:35 BM2LTS-N64native-MCLI systemd[1]: Failed to start Video Disk Recorder.

    cinfo bitte vdr neu bauen

    mpv with drm use software decoder only :(

    You can look at cpu loading.

    Thx .. so you suggest to not use-v drm. cinfo i guess this will not work for us as X is not running...if so which output plugin should we use ?

    Or should we better use another video plugin ?

    Epgsearch hat mir den ORFs auch noch seine liebe Not:


    Nachdm ich am ORF einen Suchtimer angelegt habe crasht der vdr und dann hängt er in der crash Schleife fest:

    Grund: Beim timer conflict check rast er jedes mal wieder ... siehe am Ende des logs

    da hängt der vdr dann in einer crash Schleife, weil der confilct check beim Start läuft


    Erst wenn ich die ORF-Timer aus der timer.conf lösche kommt der vdr wieder hoch ...


    Code
    1:S19.2E-1-1007-4911:2021-03-15:2158:2253:50:99:New Amsterdam~Dankbarkeit:<epgsearch><channel>1 - ORF1 HD</channel><searchtimer>New Amsterdam</searchtimer><start>1615841880</start><stop>1615845180</stop><s-id>1</s-id><eventid>44827</eventid></epgsearch>
    1:S19.2E-1-1007-4911:2021-03-16:0158:0248:50:99:New Amsterdam~Dankbarkeit:<epgsearch><channel>1 - ORF1 HD</channel><searchtimer>New Amsterdam</searchtimer><start>1615856280</start><stop>1615859280</stop><s-id>1</s-id><eventid>44833</eventid></epgsearch>