Posts by mikelh

    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

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

    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


    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


    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:

    Code
    1. 18:27:49 T:1547481264 DEBUG: int PVR::CPVRClients::RegisterClient(ADDON::AddonPtr) - registering add-on 'VDR XVDR Client'
    2. 18:27:49 T:1547481264 DEBUG: PVR - ADDON_STATUS PVR::CPVRClient::Create(int) - creating PVR add-on instance 'VDR XVDR Client'
    3. 18:27:49 T:1547481264 DEBUG: ADDON: Dll Initializing - VDR XVDR Client
    4. 18:27:49 T:1547481264 ERROR: ADDON: Could not locate ../../org.xvdr.addon/lib/libxvdraddon.so
    5. 18:27:49 T:1547481264 WARNING: bool PVR::CPVRClients::UpdateAndInitialiseClients(bool) - failed to create add-on VDR XVDR Client, status = 6
    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
    7. 18:27:49 T:1511750104 DEBUG: CGUIMediaWindow::GetDirectory (addons://disabled/xbmc.pvrclient)
    8. 18:27:49 T:1511750104 DEBUG: ParentPath = [addons://disabled/xbmc.pvrclient]
    9. 18:27:49 T:1549901912 NOTICE: Thread BackgroundLoader start, auto delete: false
    10. 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

    sorry, war unpräzise. das Problem tritt bei "Das Erste HD" auf.


    EDIT: Ich habe testweise einen Timer auf Das Erste (SD) angelegt - hier funktioniert es. Damit käme ich durchaus zurecht. danke.


    Ich bin momentan nicht direkt an dem Thema dran, da gerade erst aus dem Urlaub zurück.
    Bei meinen letzten Tests ergab sich ein ziemlich merkwürdiges Verhalten.
    Ich habe daraufhin die Statusseite des TSS-400 (firmware v .512) während der channel changes beobachtet.
    Der TSS-400 hat mit SD-Kanälen perfekt funktioniert, egal ob öff.-rechtl. oder private.
    Probleme gab es IMMER nur beim umschalten SD->HD (DVB-S -> DVB-S2) oder HD-HD,
    getestet mit ARD (HD) und ZDF (HD).
    Dabei zeigte der TSS-400 status beim Umschalten SD->HD (z.B. von RTL auf ZDF-HD) an,
    dass die tuning parameter (Frequenz, Symbolrate, Modulation) NICHT geändert wurden,
    aber die PIDs von z.B. RTL auf die PIDs von ZDF geändert wurden.
    Damit kann natürlich nichts mehr funktionieren.


    Wegen TCPdumps schaue ich mal, was ich nächstes WE erreiche, aber ich fürchte, der TSS-400
    ist totaler Murks.


    Viele Grüsse
    Mike

    Hi,
    ich mache gerade ähnliche Erfahrungen.
    Setup:
    Ubuntu 14.04 minimal
    vdr ppa alle auf fnu-main, fnu-testing
    vdr 2.1.6
    satip 0.3.3
    libcurl 7.36.0
    vdr + streamdev + dummydevice + live frisch aus den Paketen bei fnu compilert
    und als headless in einer Virtualbox installiert.
    Triax TSS-400 mit Flachantenne, 4 feeds direkt verbiunden.


    Älteres System mit IPTV-plugin unter vdr2.0.5 funktioniert seit Monaten.


    Neues setup: jegliches tuning auf DVB-S2 funktioniert nicht. Interessant dabei ist,
    dass die Statusseite des TSS-400 zwar zeigt, dass die PIDs z.B. beim Tunen von RTL
    auf ZDF-HD, korrekt geändert wurden, aber weder die Frequenz noch weitere Einstellungen
    für das Frontend übenommen wurden. Es bleibt einfach bei den Parametern, die der letzte
    SD-Kanal hatte.


    Scheint, dass der Triax beim tunen für DVB-S2 anders reagiert als für DVB-S, was die
    Parameter bei der Einstellung angeht.
    Versuche z.Zt., das ganze durch weitere debug outputs im satip-plugin zu verifizieren
    und ggf. die Ursache zu finden.
    Etvl. könnte die Trennung von tuning und channel select im der Methode Connect()
    die Ursache ein?
    Dies scheint bei der vtuner/satip-Lösung anders zu sein als im SATIP-Plugin.


    Gruss
    Micha

    Hi Jondalar,
    ich habe gesterm ein paar kurze Tests mit streamdev server, Restful-API und VLC gemacht.
    Über Restful bekomme ich mit, welcher Timer / welche Time gerade aktiv sind und aufnehmen.
    Auch kann ich die record-IDs von Aufnamhen auslesen und mit diesen dann z.B. via VLC an den streamdev-server gehen zum Abspielen.
    Leider gibt es keine einfachen Weg, um aus den Informationen des Timers auf die record-ID zu kommen, dazu scheint es erfordelich zu sein,
    den Filenamen innherhalb des Plugins nachzubilden.
    Weiterhin hat der VLC hier als streamdev-client die Wiedergabe anscheinend an der Stelle abgebrochen, bis zu dem das File bein start des
    streaminings geschrieben war, obwohl die Aufnahme noch weiter lief.
    Dies deutet darauf hin, dass der Aufwand doch wesentlich grösser ist, als anfänglich gedacht.
    Ich hoffe, am Wochenende etwas mehr Zeit zum Testen zu finden, mal sehen, was Restful und Streamdev noch so hergeben.


    Mei Setup ist übrigens recht komplex.
    Am TV selbst steht ein Mac-mini mit lokaler 2TB HDD, Plex server und PHT client.
    Userinterface i.W. über Plex Home Theater und Aplle Remote oder wireless Keyboard.
    Hier sollte ursprümlich der VDR in einer Virtualbox laufen, aber ich muss noch das Powerhandling für
    Timer-Aufnahmen lösen. PHT implementiert den Sleep für den Rechner leider so,
    dass dieser nicht einfach extern blockiert werden kann und mir den VDR lahm legen würde.
    Daher z.Zt. VDR als reiner headless server im Netzwerk, Empfang via SAT>IP mit einem Triax TSS400


    Weiterhin eine Synology DS212j mit 2x3TB HDD (mirrored) als NAS, hier kommen die Aufnahmen des VDR auch drauf.
    Ebenfalls mit Plex Server und VDR recordings Plugin. Dieser PMS gibt alle Aufzeichnungen vom VDR ins Netzwerk.
    Als PHT clients noch 2 MacBooks sowie 2 iPads und 2 iPhones und 1 Chromecast --> diese alle nur gelegentlich und nicht voll integriert
    bis auf die MacBooks.

    Jondalar :
    Danke für das Plugin, läuft soweit wirklich gut.
    Das einzige, was wirklich fehlt, ist die Wiedergabe (streaming) von Aufnahemne, die gerade laufen, sprich time-shift.
    DIese werden leider mit dem recordings-plugin nicht vollständig vom PMS wiedergegeben, er stoppt irgendwann vor dem Ende.
    Meine Idee ist, das Live-Programm um eine Abfrage, welche Timer gerade aufnehmen zu erweitern und dann
    via streamdev diese noch laufenden Aufnahmen im Live-Kanal mit zur Verfügung zu stellen. Damit sollte timeshift auch unter Plex
    möglich werden.
    Ist der Timer bereits fertig, liegt die Aufzeichnung ja komplett als recording vor und müsste hier nicht mehr behandelt werden.


    Der andere Punkt ist das Buffering von Plex bei Beginn der Wiedergabe / channel change. Hier habe ich auch noch keine
    Patetlösung gefunden und das senkt bei mir gerade den WAF ziemlich stark.


    Bin gerne bereit, mit meinen (noch bescheidenen) Python-Kentnissen an diesen Punkten mitzuwirken.


    Gruß
    Micha