hier ist ein boot log
Beiträge von clh27
-
-
Danke für das feedback. Ein aktuelles log habe ich leider nicht, der letzte start war vor 27 Tagen.
Auch wenn CHAN auf einem headless eigentlich sinnlos ist, so nutze ich es doch, um einen EIT-scan anzustossen. Daher wäre die Rückgabe des gewählten Kanals in meinen Auge die konsistente Lösung. Den automatischen EIT-scan kann ich in meinem Setup leider nicht verwenden, dann hängt sich meine Selfsat IP22 (mit SATIP-Plugin) permanent auf und muss neu gestartet werden. Anscheinend sind die Kanalwechsel zu schnell für das arme Ding.
Ich mache jetzt den EIT scan über ein nächtliches shell script, dass alle 40s den Kanal wechselt. Das klappt ohne Probleme. Es wäre nur schön, als feedback für das script den gewählten Kanal zurück zu bekommen. Alternativ könnte der EIT-scan vlt. da mit einem Delay-Parameter künstlich langsam gemacht werden? Letztendlich liegt das Problem hier nicht im vdr, sondern in der IP22.
-
ja, dummydevice ist klar, doch soll vdr ja auch ohne dieses laufen (und tut es auch).
Mal sehen, was kls sagt, er will sich das ansehen. Wäre schön, wenn es auch ohne dummydevice gehen würde.
-
rell: ist das auch ein headless vdr? Ich vermute eine mögliche Ursache im headless-Betrieb.
-
Ich habe ein merkwürdiges Phänomen bei der Kanalumschaltung mit svdrp.
Setup: vdr: 2.6.4 als headless server in container mit plugin satip an Selfsat IP22, als clients diverse Geräte mit Kodi via vnsi.
Die Kanalumschaltung mit svdrp gibt nach Umschaltung den falschen Kanal zurück (immer Kanal 1), tuned aber korrekt auf den gewählten neuen Kanal.
Dies ist auch im webinterface des satip-servers zu sehen, der neue Transponder wird korrekt verwendet.
Auch "plugin satip info" zeigt, dass auf den richtigen transponder getuned ist, gibt aber ebenfalls die falsche channelinfo zurück.
Beispiel: switching to channel 19 mit svdrpsend
command and output:
$ svdrpsend chan 19 <-- das ist bei mir der RTL Transponder
220 vdr SVDRP VideoDiskRecorder 2.6.4; Mon Nov 13 10:29:33 2023; UTF-8
250 1 Das Erste HD
221 vdr closing connection
syslog:
2023-11-13T10:28:57.896974+01:00 vdr vdr: [174] SVDRP vdr < 127.0.0.1:41932 client connection accepted
2023-11-13T10:28:57.897033+01:00 vdr vdr: [174] SVDRP vdr > 127.0.0.1:41932 server created
2023-11-13T10:28:57.897246+01:00 vdr vdr: [174] switching to channel 19 S19.2E-1-1089-12003 (RTL Television)
2023-11-13T10:28:58.162810+01:00 vdr vdr: [174] SVDRP vdr < 127.0.0.1:41932 connection closed
2023-11-13T10:28:58.162918+01:00 vdr vdr: [174] SVDRP vdr < 127.0.0.1:41932 server destroyed
2023-11-13T10:29:29.256481+01:00 vdr vdr: [142] SATIP: Idle timeout - releasing [device 0]
checking satip plugin stat and info:
root@vdr:/build/vdr-2.6.4# svdrpsend plug satip stat
220 vdr SVDRP VideoDiskRecorder 2.6.4; Mon Nov 13 10:29:46 2023; UTF-8
900-Device: SAT>IP 0
900-CardIndex: 0 HasLock: yes Strength: 61 Quality: 100 Live: yes
900-Transponder: 112188
900-
900-Device: SAT>IP 1
900-CardIndex: 1 HasLock: no
900-Transponder: 212363
900-
900-Device: SAT>IP 2
900-CardIndex: 2 HasLock: no
900-Transponder: 212480
900-
900-Device: SAT>IP 3
900-CardIndex: 3 HasLock: no
900-Transponder: 212522
900
221 vdr closing connection
root@vdr:/build/vdr-2.6.4# svdrpsend plug satip info
220 vdr SVDRP VideoDiskRecorder 2.6.4; Mon Nov 13 10:29:48 2023; UTF-8
900-SAT>IP device: 0
900-CardIndex: 0
900-Stream: rtsp://192.168.1.159/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34 (Unicast) [stream=130]
900-Signal: lock=1 strength=61 quality=100 frontend=1
900-Stream bitrate: 840 kbit/s
900-Buffer bitrate: 0 kbit/s
900-Buffer usage: 0/16384 kbit (0,0%)
900-Channel: Das Erste HD;ARD:11494:HC23M5O35P0S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
900-Active pids:
900-Active section filters:
900-Filter 0: 1028 ( 552 kbit/s) Pid=0x12 (EIT)
900-Filter 1: 14 ( 0 kbit/s) Pid=0x14 (TDT)
900-Filter 2: 29 ( 0 kbit/s) Pid=0x00 (PAT)
900-Filter 3: 7 ( 0 kbit/s) Pid=0x11 (SDT)
900 Filter 4: 2 ( 0 kbit/s) Pid=0x10 (NIT)
221 vdr closing connection
root@vdr:/build/vdr-2.6.4#
-
Rolf,
I always see this behaviour in my docker container's log:
2016-06-08 15:50:28,stdout,"2016-06-08T17:50:28.376838+02:00 vdr vdr: [141] [poller.c,82]: epoll_wait() failed: Interrupted system call
2016-06-08 15:49:56,stdout,2016-06-08T17:49:56.798816+02:00 vdr vdr: [148] SATIP: Idle timeout - releasing [device 2]
2016-06-08 15:49:56,stdout,2016-06-08T17:49:56.068025+02:00 vdr vdr: [151] SATIP: Idle timeout - releasing [device 3]
2016-06-08 15:49:11,stdout,"2016-06-08T17:49:11.117739+02:00 vdr vdr: [141] [poller.c,82]: epoll_wait() failed: Interrupted system call
2016-06-08 15:47:54,stdout,"2016-06-08T17:47:54.870881+02:00 vdr vdr: [141] [poller.c,82]: epoll_wait() failed: Interrupted system call
2016-06-08 15:47:48,stdout,2016-06-08T17:47:48.403226+02:00 vdr vdr: [148] SATIP: Idle timeout - releasing [device 2]
2016-06-08 15:47:48,stdout,2016-06-08T17:47:48.295588+02:00 vdr vdr: [151] SATIP: Idle timeout - releasing [device 3]
2016-06-08 15:46:37,stdout,"2016-06-08T17:46:37.351945+02:00 vdr vdr: [141] [poller.c,82]: epoll_wait() failed: Interrupted system call
2016-06-08 15:45:40,stdout,2016-06-08T17:45:40.683869+02:00 vdr vdr: [148] SATIP: Idle timeout - releasing [device 2]
2016-06-08 15:45:40,stdout,2016-06-08T17:45:40.021833+02:00 vdr vdr: [151] SATIP: Idle timeout - releasing [device 3]
2016-06-08 15:45:20,stdout,"2016-06-08T17:45:20.822894+02:00 vdr vdr: [141] [poller.c,82]: epoll_wait() failed: Interrupted system callusing a digibit R1 with 4 tuners running under Satip-AXE Version satip-axe-201605311610-12.fw, VDR 2.2 with vdr-plugin-satip 2.2.x
docker soultion adapted from chriszerohope you can use this info
Best regards and thanks much for your efforts providing SAT>IP for VDR, appreciate that.
Michael
-
bitte sieh dir die container Konfiguration an was das Netzwerk angeht.
Wenn da NAT aktiv ist, dass ist das Netz idR 172.rigendwas
Das muss im streamdev entsprechend enabled sein. -
Danke an alle!
habe jetzt nochmals Isengard als auch Jarvis unter OSX Mavericks und El Capitan mit VNSI getestet,
und es scheint den WAF wieder auf 100% zu bringen. Ebenso mit OpenELEC 6 auf dem Raspberry PI 2.
Timeshift läuft und zeitversetzte Aufnahmen scheinen auch OK zu sein.
Fehlt noch Amazon FireTV (1. Generation) und Dragonboard 410 mit Debian Jessie ... das kommt an einem der
nächsten WEs (hoffentlich).Dann ist XVDR jetzt Geschichte...
Gruß
Micha -
Das hatte ich auch mal vor einiger Zeit. Aber mit dem aktuellen Softwarestand der bei mir läuft gibt es das Problem schon lange nicht mehr.
das klingt interessant.
Welche Version verwendest Du, und wie ist timeshift konfiguriert?
Werde ich mal unter 15.2 testen, vielen Dank. -
bei VNSI hakelt es mit zeitversetztem TV.
Konkretes Beispiel:
Sendung von 20:15 - 21:15, Timer mit Vor- und Nachlauf 20:10 - 21:25 (hier komme ich noch drauf zurück)
Aufnahme läuft seit 20:10, um 20:22 komme ich heim und möchte diese Senddung sehenmit XVDR: TV->Aufnahmen->Aufzeichnung auswählen und Wiedergabe
Dort kann ich dann währen der Wiedergabe vor- und zurückspringen und die Aufnahme bis zum Ende der Sendung ansehen.mit VNSI: TV-Aufnahmen->Aufzeichnung auswählen und Wiedergabe
Bei VNSI wird die Wiedergabe leider an dem Punkt der Aufnahme beendet, an dem man agngefangen hat zu schauen, also hier
nach 12 Minuten, zum Aufnahmezeitpunkt 20:22ODER:
ich muss VNSI so konfigurieren, dass statt Live-TV die laufende Aufnahme angezeigt wird.
Dies ist aber keine Selektion sonder nur in der Konfiguration möglich!
Dann geht zumindest bei mir leider weder vor- noch zurückspringen während der Wiedergabe (selbst über Bildschirmmenü nicht möglich!),
d.h. ich muss den Timervorlauf (5 Min) abwarten und ausserdem jegliche Werbung ertragen -> dies ist das 1. der no-goFerner kann ich so auf dem Kanal während der Nachlaufzeit des Timers (s.o.) von 21:15 bis 21:25
KEIN Live-TV wie die nachfolgende Sendung ansehen, da ja die Konfiguration sagt: Aufnahme wiedergeben -> 2. no-goAuch wenn argumentiert wird, dass VNSI von der Logik her für single Tuner-Systeme gedacht sei,
so leuchten mir diese Einschränkungen nicht ein.Damit hat VNSI den WAF bei nahe Null erhalten (und meinen leider auch) und ich setze bislang XVDR ein.
Allerdings würde ich gerne wegenb anderer Pluig-ins von XVDR Gotham auf Kodi Isengard oder später auch Jarvis upgraden.Der Versuch, das XVDR-Plugin unter OSX selber aufzusetzen scheitert leider bei mir.
Compilieren klappt, wenn ich das Makefile anpasse jedoch crasht das Plugin sowohl unter Kodi 15.2 wie auch unter 16.2.
Daher die Frage, ob es jemand bereits erfolgreich unter OSX verfügbar hat.Gruß
Micha -
hat jemand das fertig gebaute XVDR addon für Kodi 15.2 unter OSX?
VNSI ist definitiv ein ungenügender Ersatz, der WAF geht hier gegen Null
oder gibt es ein howto zum selber compilieren? Da hatte ich bislang keinen Erfolg, das
gebaute Plugin laufen zu lassen, Kodi 15.2 crasht da komplett.Danke und Grüße
Micha -
Dank an cinfo!
Ich have jetzt TVMC + XVDR addon auf dem FireTV erfolgreich installieren können, hier ein erstes
Fedback, ich konnte nur kurzs damit testen. Logfiles erst am WE wenn ich wieder daheim bin.Leider stürzt TVMC häufig direkt nach dem ersten start der App ab, beim 2. start läuft es dann aber.
xvdr funktioniert auch, LiveTV in HD (das Erste) und SD (Vox) getested, funktionier scheinbar auch,
Wiedergabe von Aufnahmen in SD sind auch OK,
Wiedergabe von Aufnahmen in HD fühen sofort zum crash von TVMC.Danke und Gruß
Mike -
Hallo cinfo,
danke für den Tipp.
Ist das die Datei "/sdcard/Android/data/org.xbmc.xbmc/files/.xbmc/addons/pvr.vdr.xvdr/addon.xml"?
Die Änderung dort hat leider nicht geholfen, das Addon lässt sich nicht aktivieren,
der Fehler im log ist nun "ERROR: ADDON: Could not locate ../org.xvdr.addon-1/lib/libxvdraddon.so"Gruß
Mike -
weder der patch, noch das zip-file sind online (error 404)
-
ich weiss nicht, was sich wo getan hat.
Mir ist der WAF wichtig, und den habe ich zu 100% mit der XVDR-Lösung.
VNSI habe ich deshalb nie getestet. -
Hallo sh4,
danke für das Video, sieht ja ganz gut aus.
Allerdings habe ich gelesen, dass timeshift bei VNSI nicht so gut funktioniert wie bei XVDR.
"Live-TV geht auch mit VNSI, steige ich aber damit in eine laufende Aufnahme ein, kann diese nur bis zum
Einstiegszeitpunkt angesehen werden. XVDR zeigt auch laufende Aufnahmen bis zum Ende an"Das timeshift-playback mit XVDR perfekt läuft kann ich bestätigen und das ist für mich der entscheidende Faktor, da ich eigentlich
immer timeshift verwende.Gruss
Micha -
zu 1.: Senderlogos hab ich bei VNSI doch auch
zu 2.: VNSI bei mir auch
zu 3.: Kann ich keine Aussagen treffen. Müsste ich mal austesten. Kann mir aber nicht vorstellen, dass das nicht geht.zu 1.: Senderlogos hab ich bei VNSI doch auch
zu 2.: VNSI bei mir auch
zu 3.: Kann ich keine Aussagen treffen. Müsste ich mal austesten. Kann mir aber nicht vorstellen, dass das nicht geht.wie sieht es bei VNSI aus mit:
4) Timerprogrammierung
5) EPG
6) VideoText
(sorry, ich habe nur XVDR installiert, und das läuft mit VDR server (Linux) <-> XBMC unter OS-X ziemlich perfekt)
Gruss
Mike -
Kann es sein das die Firmware mittlerweile den Session Fehler behoben hat und dieser Workaround nicht mehr nötig ist?
Oder ev hat sich die description geändert?
Server.c vom SatIP 0.3.3
lg,
JoeHallo Joe,
das Problem tritt ebenfalls mit der aktuellen firmware des TSS-400 auf,
und bleibt auch bestehen, wenn die Session wie in der SAT>IP spec eigentlich
gefordert, jedesmall nach einem request geschlossen wird (s. mein letztes posting).VG
Mike -
das ist ja genau das von mir bereits beschriebene Verhalten des TSS-400.
Danke darkover für die Bestätigung, damit sollte es sich wahrscheinlich nicht um einen
Hardwarefehler handeln, zumal das tuning manchmal (aber leider nicht reproduzierbar)
auch problemlos klappt.
In der Zwischenzeit habe ich die libcurl-Optionen so gesetzt, dass ein "session close"
mit im Header ist (patch hierzu folgt noch), aber das hatte leider auch nicht den gewünschten Erfolg.Gruss
Micha -
Hi,
hier wäre der letzte Stand für das Add-on für XBMC
gotham: http://dl.dropbox.com/u/240579/xvdr-android/gotham/xbmc-addon-xvdr-debug.apk
OK, das xvdr Version 0.97 muß man erst registrieren als App, dann erscheint es im XBMC/PVR -- im ersten Test lief es auch gut an.
Grüße
cinfoHallo cinfo,
wie hast Du das zum laufen gebracht?Bei mir scheitert der Start des Addons mit einem Fehler, das log zeigt, dass eine library nicht gefunden wird:
Code18:27:49 T:1547481264 DEBUG: int PVR::CPVRClients::RegisterClient(ADDON::AddonPtr) - registering add-on 'VDR XVDR Client' 18:27:49 T:1547481264 DEBUG: PVR - ADDON_STATUS PVR::CPVRClient::Create(int) - creating PVR add-on instance 'VDR XVDR Client' 18:27:49 T:1547481264 DEBUG: ADDON: Dll Initializing - VDR XVDR Client 18:27:49 T:1547481264 ERROR: ADDON: Could not locate ../../org.xvdr.addon/lib/libxvdraddon.so 18:27:49 T:1547481264 WARNING: bool PVR::CPVRClients::UpdateAndInitialiseClients(bool) - failed to create add-on VDR XVDR Client, status = 6 18:27:49 T:1547481264 WARNING: bool PVR::CPVRClients::UpdateAndInitialiseClients(bool) - failed to load the dll for add-on VDR XVDR Client, disabling it 18:27:49 T:1511750104 DEBUG: CGUIMediaWindow::GetDirectory (addons://disabled/xbmc.pvrclient) 18:27:49 T:1511750104 DEBUG: ParentPath = [addons://disabled/xbmc.pvrclient] 18:27:49 T:1549901912 NOTICE: Thread BackgroundLoader start, auto delete: false 18:27:49 T:1549907152 DEBUG: static CStdString CTextureCacheJob::GetImageHash(const CStdString&) - unable to stat url /data/data/org.xbmc.xbmc/cache/apk/assets/addons/pvr.demo/icon.png
Welches apk hast Du denn für XBMC Gotham verwendet?
Viele Grüsse
Micha