Handhabe das Problem mit vdr-plugin-duplicates, eventl. kann man sich da was abkucken.
Posts by vdr_rossi
-
-
Geht es denn unter Windows?
Aktuelle Intel Grafikkarten haben das gleiche Problem, aber da funktioniert es zumindest unter Windows -> Klick
-
Kannst du genauer beschreiben, was du vor den Crash gemacht hast - also läuft da gerade ein Schnitt, eine Aufnahme usw.? War die gelöschte Aufnahme am Anfang, Mitte oder Ende der OSD-Liste?
Also: Es läuft live TV, bin im OSD (Skin Klassik) in den Aufnahmen, es wurde eine Aufnahme geschnitten, geschnittene Aufnahme erscheint bei meiner Sortierung über der ursprünglichen Aufnahmen, drücke die gelbe Taste zum löschen der ursprünglichen Aufnahme - Crash. Das OSD wurde dabei nicht verlassen.
Aber wie schrieben, es passiert sporadisch. Lässt sich nicht immer reproduzieren.
QuoteDas liefe ich beim nächsten Crash nach.
Danke für die Mühe! Überschaubare Pluginliste siehe Beitrag #1 -
Eben ist es mal wieder passiert. Hat keiner eine Idee? bzw. kann den bt "lesen" ?
-
Was steht in /usr/share/vdr/recording-hooks/R90.custom ?
Steht im Beitrag #1
-
Löscht du die Aufnahmen über das normale Aufzeichnungsmenü des VDR (nicht dass da noch sowas wie extrecmenu mit hinein spielt)?
Ja, in der ganz normalen Aufnahmeliste vom vdr - mit der gelben Taste.
Extrecmenu verwende ich nicht, siehe Pluginliste #1
-
Zu früh gefreut, eben ist es wieder passiert - Ausgabe im Anhang.
Reicht das um die Ursache zu erkennen? Mein Wissen reicht nicht zur Fehlersuche...
Danke
-
Danke für die Hinweise!
Habe ich so umgesetzt. Ebenso habe ich iHD und lib-va & tools auf den neusten Stand gebracht. Was soll ich sagen, crashed passiert nicht mehr.
Stresstest mit 20-30 Aufnahmen schneiden, löschen, usw. alles ohne Crash.
Beobachte es trotzdem noch etwas - bevor ich das auf gelöst setze. Vor Fehlersuche noch Sachen verändern, das macht man nicht...
Aber das Ergebnis zählt.
-
Hallo,
habe Ubuntu 20.04 LTS mit vdr ansible laufen. Alles auf aktuellem Stand, siehe auch Signatur.
Ich schneide eine Aufnahme und lösche die original Aufnahme:
Display MoreCode- ...
- Dec 31 14:28:10 vdr1 vdr: [3123] confirm: Aufzeichnung löschen?
- Dec 31 14:28:10 vdr1 vdr: [3123] warning: Aufzeichnung löschen?
- Dec 31 14:28:11 vdr1 vdr: [3123] confirmed
- Dec 31 14:28:11 vdr1 vdr: [3123] deleting recording '/srv/vdr/video/Bauerfeind_-_Die_Show_zur_Frau/2020-12-18.21.13.15-0.rec'
- Dec 31 14:28:11 vdr1 vdr: [3123] renaming '/srv/vdr/video/Bauerfeind_-_Die_Show_zur_Frau/2020-12-18.21.13.15-0.rec' to '/srv/vdr/video/Bauerfeind_-_Die_Show_
- Dec 31 14:28:11 vdr1 vdr: [3123] executing '/usr/lib/vdr/vdr-recordingaction deleted "/srv/vdr/video/Bauerfeind_-_Die_Show_zur_Frau/2020-12-18.21.13.15-0.del
- Dec 31 14:28:11 vdr1 recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom as shell script
- Dec 31 14:28:11 vdr1 kernel: [ 8800.335251] show_signal: 18 callbacks suppressed
- Dec 31 14:28:11 vdr1 kernel: [ 8800.335255] traps: vdr[3123] general protection fault ip:55dcf1aef8a0 sp:7ffe403565a8 error:0 in vdr[55dcf1a0b000+f5000]
- Dec 31 14:28:12 vdr1 yavdr-frontend[1299]: INFO:pydbus2vdr:VDR Status: stopped
- Dec 31 14:28:12 vdr1 yavdr-frontend[1299]: DEBUG:softhdvaapi:g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name de.tvdr.vdr
- Dec 31 14:28:12 vdr1 systemd[1]: vdr.service: Main process exited, code=dumped, status=11/SEGV
- Dec 31 14:28:12 vdr1 systemd[1]: vdr.service: Failed with result 'core-dump'.
- Dec 31 14:28:12 vdr1 systemd[1]: vdr.service: Scheduled restart job, restart counter is at 1.
- Dec 31 14:28:12 vdr1 systemd[1]: Stopped Video Disk Recorder.
- Dec 31 14:28:12 vdr1 systemd[1]: Starting Video Disk Recorder...
- Dec 31 14:28:12 vdr1 vdr: [4044] VDR version 2.4.6 started
- Dec 31 14:28:12 vdr1 vdr: [4044] switched to user 'vdr'
- Dec 31 14:28:12 vdr1 vdr: [4044] codeset is 'UTF-8' - known
- Dec 31 14:28:12 vdr1 vdr: [4044] found 28 locales in /usr/share/locale
- Dec 31 14:28:12 vdr1 vdr: [4044] no locale for language code 'alb,sqi'
- ...
Wie gehe ich der Sache auf den Grund?
Plugins nach und nach deaktivieren? Die Liste ist nicht lang:
Display MoreCode- root@vdr1:/home/rossi# vdr --showargs
- --record=/usr/lib/vdr/vdr-recordingaction
- --user=vdr
- --grab=/tmp
- --port=6419
- --watchdog=0
- --shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
- --dirnames=,,1
- --lirc=/var/run/lirc/lircd
- --plugin=conflictcheckonly
- --plugin=dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hook s-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
- --plugin=desktop
- --plugin=devstatus
- --plugin=duplicates
- --plugin=epgsearch
- --plugin=epgsearchonly
- --plugin=femon
- --plugin=markad --astopoffs=0 --cDecoder
- --plugin=menuorg
- --plugin=osd2web
- --plugin=pulsecontrol
- --plugin=quickepgsearch
- --plugin=screenshot
- --plugin=softhdvaapi -D
- --plugin=systeminfo
Der Inhalt von /usr/share/vdr/recording-hooks/R90.custom ist Standard:
Display MoreCode- #
- # If you want to create your own recording hook that may get executed
- # before any other hook, create it in /usr/share/vdr/recording-hooks or
- # link to this location. All hooks are called in their alphabetical
- # order and should follow this naming scheme:
- #
- # R<XX>.<identifier>
- #
- # Where <XX> is a two digit number, that mainly specifies the execution order
- # and <identifier> is a unique descriptor.
- #
- # Two parameters are passed:
- #
- # Parameter 1 can have the values "before", "after" and "edited", depending
- # on whether the recording hook is called before the recording starts,
- # after the recording ends or after the recording has been edited.
- #
- # Parameter 2 is the directory of the recording. Be aware, that this directory
- # doesn't exist before the recording starts.
- #
- case $1 in
- before)
- # do here whatever you would like to do right BEFORE
- # the recording $2 STARTS
- ;;
- started)
- # do here whatever you would like to do right AFTER
- # the recording $2 STARTED
- ;;
- after)
- # do here whatever you would like to do right AFTER
- # the recording $2 ENDED
- ;;
- edited)
- # do here whatever you would like to do right AFTER
- # the recording $2 has been EDITED
- # $3 is the original recording
- ;;
- deleted)
- # do here whatever you would like to do right AFTER
- # the recording $2 has been DELETED
- ;;
- esac
Danke
-
-
CEC auf dem NUC geht mW immer nur eingeschränkt, wenn man nicht einen CEC-Adapter nachrüstet. In meinem NUC7 läuft der interne Adapter von Pulse-Eight absolut streßfrei und tut alles, was man erwartet (nachdem ich rausgefunden habe, daß er wohl hart mit dem Port HDMI2 verdrahtet ist
)Der NUC7 hat 2x HDMI? Funktioniert also nur an dem einen HDMI...
Laut cec-info ist das falsche source active:
Display MoreCode- root@vdr1:/home/rossi# echo "scan" | cec-client -s -d 1
- opening a connection to the CEC adapter...
- requesting CEC bus information ...
- CEC bus information
- ===================
- device #0: TV
- address: 0.0.0.0
- active source: no
- vendor: Philips
- osd string: TV
- CEC version: 1.4
- power status: on
- language: ger
- device #1: Recorder 1
- address: 1.0.0.0
- active source: yes
- vendor: Philips
- osd string: CECTester
- CEC version: 1.4
- power status: on
- language: eng
- currently active source: Recorder 1 (1)
- root@vdr1:/home/rossi# systemctl cat libcec-daemon.service
- # /etc/systemd/system/libcec-daemon.service
- [Unit]
- Description=translate cec events to uinput key presses
- [Service]
- Environment=DISPLAY=:0
- ExecStart=/usr/bin/libcec-daemon -p 0.0.0.0
- [Install]
- WantedBy=multi-user.target
obwohl ich 0.0.0.0 als Startport übergebe...
Wie setze ich device #0 aktiv?
-
Hast du das vdr-plugin-cec und ggf. andere Programme, die auf die CEC-Schnittstelle zugreifen deaktiviert?
Nein, habe im Playbook geschaut - da ist nix mit cec. Meine Startargs:
Display MoreCode- root@vdr1:/home/rossi# vdr --showargs
- --record=/usr/lib/vdr/vdr-recordingaction
- --user=vdr
- --grab=/tmp
- --port=6419
- --watchdog=0
- --shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
- --dirnames=,,1
- --lirc=/var/run/lirc/lircd
- --plugin=conflictcheckonly
- --plugin=dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hook s-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
- --plugin=desktop
- --plugin=devstatus
- --plugin=duplicates
- --plugin=epgsearch
- --plugin=epgsearchonly
- --plugin=femon
- --plugin=markad --astopoffs=0 --cDecoder
- --plugin=menuorg
- --plugin=osd2web
- --plugin=pulsecontrol
- --plugin=quickepgsearch
- --plugin=screenshot
- --plugin=softhdvaapi -D
- --plugin=systeminfo
Wie finde ich das raus, wer oder was eventl. auf die cec Schnittstelle zugreift?
-
Das vdr-plugin-cecremote und der libcec-daemon dürften sich gegenseitig behindern, wenn die gleichzeitig laufen, weil sich der erste laufende Prozess das Gerät schnappt.Laut README.md kann man dem libcec-daemon das Gerät explizit als Startargument mitgeben, falls die automatische Erkennung nicht klappt: https://github.com/bramp/libcec-daemon#usage - wenn du die libcec-daemon.service (die kannst du dir mittels systemctl cat libcec-daemon.service anzeigen lassen) anpasst (bzw. einen Override erstellst systemctl edit --full libcec-daemon.service), kannst du die Startargumente beeinflussen.
Möchte den pulse-eight cec Adapter nur mit libcec-daemon verwenden.
Der Hinweis oben wurde übergangen und nur vom vdr-plugin-cecremote geschrieben.
Als erstes habe ich persystemctl edit --full libcec-daemon.service die Startargumente gesetzt:
Default ist -a (donotactivate) - dann Neustart.
Kein Erfolg.
Scan per cec-client (cec-utils):
Display MoreCode- root@vdr1:/home/rossi# echo "scan" | cec-client -s -d 1
- opening a connection to the CEC adapter...
- requesting CEC bus information ...
- CEC bus information
- ===================
- device #0: TV
- address: 0.0.0.0
- active source: no
- vendor: Philips
- osd string: TV
- CEC version: 1.4
- power status: on
- language: ger
- device #1: Recorder 1
- address: 1.0.0.0
- active source: yes
- vendor: Philips
- osd string: CECTester
- CEC version: 1.4
- power status: on
- language: eng
- currently active source: Recorder 1 (1)
im syslog:
Code- Dec 28 18:47:40 vdr1 kernel: [ 4.261167] usbhid: USB HID core driver
- Dec 28 18:47:40 vdr1 kernel: [ 4.262350] input: Pulse-Eight CEC Adapter as /devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.2/0003:2548:1002.0001/input/inp
- ut4
- Dec 28 18:47:40 vdr1 kernel: [ 4.262405] hid-generic 0003:2548:1002.0001: input,hidraw0: USB HID v1.10 Mouse [Pulse-Eight CEC Adapter] on usb-0000:00:14.0
- -6/input2
trotz systemctl stop libcec-daemon.servicekommt:
manuell gestartet:
Code- root@vdr1:/home/rossi/yavdr-ansible# libcec-daemon -p tv.1 --usb /sys/devices/pci0000:00/0000:00:14.0/usb1/1-6
- INFO - Opened /dev/uinput
- INFO - Created uinput device
- INFO - Physical Address is set to 0.0.0.0
- INFO - Base device is set to 0
- INFO - HDMI port is set to 1
- INFO - Looking for /sys/devices/pci0000:00/0000:00:14.0/usb1/1-6
- INFO - Opening /sys/devices/pci0000:00/0000:00:14.0/usb1/1-6
- Failed to open adapter
Vdr mit der Philips Fernbedienung bedienen funktioniert nicht. Nur Einschalten vom NUC funktioniert.
CEC im NUC Bios ist komplett aus.
Kann ich Tastendrücke von der TV Fernbedienung diagnostizieren?
Was muss noch definiert werden?
-
Ist ja schon ein paar Jahre her, seit ich eine Android-App gebaut hatte.. Ich hoffe, das Android Studio passt überhaupt noch auf meinen Laptop.
Ich werde mich mal damit beschäftigen. Danke für den Tip!
Da gibt es doch ein fertiges APK von -> https://github.com/pipelka/roboTV/releases
Und falls Deinem headless Server auf Ubuntu yavdr ansible basiert, ist vdr-plugin-robotv auch fertig dabei.
Ungetestet von mir - nur ein Hinweis. -
-
Ist zwar noch keine Weihnachten aber der Fernseher Kauf ist getätigt worden.
Kodi mit Plugin video.vdr.recordings funktioniert!
Beim 1. Test kamen die VDR Aufnahmen vom USB Stick (NTFS). Meine Archivplatte (exFAT) mag der Philips nicht.
Muss mir jetzt was über Netzwerk zum VDR überlegen...
-
mit libplacebo89 gehts wieder! Danke
-
nach apt-get dist-upgrade
kommt immer noch:
Code- ..
- Dec 4 23:00:10 vdr1 vdr: video: crop to +0+0 1920x1080
- Dec 4 23:00:10 vdr1 vdr: video: normal aspect output 1920x1080+0+0
- Dec 4 23:00:10 vdr1 vdr: GetFormat Init ok 1920x1080
- Dec 4 23:00:10 vdr1 kernel: [ 113.046011] video display[3721]: segfault at 1c ip 00007f64fa02d9b1 sp 00007f646ea6c810 error 4 in libplacebo.so.102[7f64fa02
- 0000+1ec000]
- Dec 4 23:00:10 vdr1 kernel: [ 113.046043] Code: f3 48 8b 36 48 85 f6 74 0d ff 97 f8 00 00 00 48 c7 03 00 00 00 00 5b c3 90 f3 0f 1e fa 41 55 41 54 49 89 fc
- 55 53 48 83 ec 08 <80> 7e 1c 00 74 39 48 8b 87 28 01 00 00 48 8d 9f f0 00 00 00 48 89
- Dec 4 23:00:10 vdr1 systemd[1]: Stopping Video Disk Recorder...
- Dec 4 23:00:11 vdr1 yavdr-frontend[1272]: INFO:pydbus2vdr:VDR Status: stopped
-
Bei Intel Ausgabe ist libplacebo auch kaputt:
Code- Dec 4 20:31:24 vdr1 vdr: video: crop to +0+0 1920x1080
- Dec 4 20:31:24 vdr1 vdr: video: normal aspect output 1920x1080+0+0
- Dec 4 20:31:24 vdr1 vdr: GetFormat Init ok 1920x1080
- Dec 4 20:31:24 vdr1 kernel: [ 122.828995] video display[3307]: segfault at 1c ip 00007fa6fd3ae9b1 sp 00007fa671dc4810 error 4 in libplacebo.so.102[7fa6fd3a
- Dec 4 20:31:24 vdr1 kernel: [ 122.829010] Code: f3 48 8b 36 48 85 f6 74 0d ff 97 f8 00 00 00 48 c7 03 00 00 00 00 5b c3 90 f3 0f 1e fa 41 55 41 54 49 89 fc
- Dec 4 20:31:25 vdr1 yavdr-frontend[1278]: INFO:pydbus2vdr:VDR Status: stopped
- Dec 4 20:31:25 vdr1 yavdr-frontend[1278]: DEBUG:softhdvaapi:g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name de.tvdr.vdr
-
Im syslog steht:
da liegt das Problem!? Der Treiber meldet in der Kombination unsinige Empfangsarten.
War vor 7 Jahren schonmal Thema: Feature Request: Beschränken von C/T Tunern auf eine Empfangsart
So wie ich das verstanden habe muss der Treiber die richtige Empfangsart melden?
