Beiträge von clh27

hier ist ein boot log

vdr-boot-log.txt

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 call

using 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 chriszero

hope 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

Zitat von meikelmoeller

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 sehen

mit 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:22

ODER:
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-go

Ferner 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-go

Auch 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

Zitat von sh4

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.

Zitat von sh4

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

Zitat von DocViper

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,
Joe

Alles anzeigen

Hallo 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

Zitat von cinfo

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
cinfo

Alles anzeigen

Hallo 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:

18: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