Tester gesucht: Streamdev-Server mit VDR 2.1.4+ Funktion ChannelChange

  • Hallo zusammen,


    unter http://projects.vdr-developer.…-0.6.1-channelchange2.tgz kann eine Testversion von Streamdev heruntergeladen werden, bei der der Server die in VDR 2.1.4 neu eingeführte Funktion ChannelChange unterstützt. Ein bestimmtes Plugin benötigt wohl diese Funktion. Ich kann es selbst leider nicht testen und bin daher auf Mithilfe angewiesen.


    [EDIT]Link auf neue Version geändert[/EDIT]

    Einmal editiert, zuletzt von schmirl () aus folgendem Grund: Link auf neue Version geändert

  • Ich habe die streamdev Plugins für YaVDR testing-vdr-dev gegen VDR 2.1.6 gebaut, das Repository findet man in folgendem PPA:

    Code
    add-apt-repository ppa:frodo-vdr/testing-vdr-dev


    oder wer nur die Pakete möchte

    Code
    wget https://launchpad.net/~frodo-vdr/+archive/testing-vdr-dev/+build/6126359/+files/vdr-plugin-streamdev-client_0.6.1.git20140624.1144-0yavdr0%7Eprecise_amd64.deb
    wget https://launchpad.net/~frodo-vdr/+archive/testing-vdr-dev/+build/6126359/+files/vdr-plugin-streamdev-server_0.6.1.git20140624.1144-0yavdr0%7Eprecise_amd64.deb


    Für YaVDR testing 2.0.6 finden sich die Pakete wie folgt:

    Code
    add-apt-repository ppa:frodo-vdr/testing-yavdr-plugins


    oder die Pakete

    Code
    wget https://launchpad.net/~frodo-vdr/+archive/testing-yavdr-plugins/+build/6126416/+files/vdr-plugin-streamdev-client_0.6.1.git20140624.1144-0yavdr0%7Eprecise_amd64.deb
    wget https://launchpad.net/~frodo-vdr/+archive/testing-yavdr-plugins/+build/6126416/+files/vdr-plugin-streamdev-server_0.6.1.git20140624.1144-0yavdr0%7Eprecise_amd64.deb

    Gruß
    Frodo

    2 Mal editiert, zuletzt von Frodo ()

  • Danke Frodo. Hast Du die von mir verlinkte Datei verwendet oder (wie es der Name der Pakete nahelegt) den aktuellen Stand aus dem git? Im git sind die Änderungen noch nicht veröffentlicht. Hätte gerne erstmal Feedback, ob die Änderung überhaupt das Gewünschte bewirkt.

  • Ich habe aus Deiner Datei und dem Git einen Patch erstellt der die git-Version so abändert das es Deiner Datei entspricht. Zum einen ist es bei neuen Änderungen die nicht im Git sind einfacher diese einzubauen und zum anderen wird die Paket Version weiter hochgezählt.
    Im VDR meldet sich das Plugin wie Du es in den Sourcen angegeben hast mit "0.6.1-channelchange".

    Gruß
    Frodo

  • @schmirl


    ich kann auf meinem stream server ( Zyxel NSA 325 , archlinux arm, vdr4arch next) keine Verbesserung erkennen. habe immer noch extreme Probleme auf die kanäle zu schalten die das bestimmte plugin benötigen.


    mal sehen was die andern User hier berichten?


    gruß
    karsten

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf

    Einmal editiert, zuletzt von niedi_74 ()

  • Ich habe auch keine Verbesserungen festgestellt, allerdings weis ich nicht ob es überhaupt an streamdev liegt.
    Da ich aber Sat>IP mit satip - Pluging oder vtunerc + satip Binary verwende mag es durchaus auch an diesen noch in den Kinderschuhen steckenden Komponenten liegen.


    FTA funktioniert ohne Probleme, Merkwürdig ist allerdings das HD+ problemlos funktioniert, Sky hingegen je nach Sender mehr oder weniger Probleme bereitet. Eventuell liegt es daran das über die Sky Karte auch HD+ möglich wäre, ich aber eine extra HD+ Karte verwende...

    Gruß
    Frodo

  • Vdr 2.1.6 with Streamdev but with the mother of the forbidden api plugin. Works ok with git. Haven't had the time to test this patch.


    Only with fast http zapping crashes streamdev so in my client I've built in a delay. Works better now.

    I'm sorry for the English postings but I can't write German, reading isn't a problem.


    VDR server: P4 with vdr 2.1.6 / streamdev / SmartTVweb / vipclient Javascript
    Clients : Motorola Vip1903/1963

  • Ich habe gerade den Live Buffer auf 50 ms gesetzt (streamdev-server.LiveBufferMs = 50) und bekomme nun direkt beim umschalten auch die Problem Sender hell.
    Ich weis nicht ob dieser Wert der optimale ist, bei kleineren Werten (10 ms und 20 ms habe ich noch probiert) klappte das Umschalten häufig nicht.

    Gruß
    Frodo

  • hi , das mit dem 50 ms vom live buffer hat auch bei mir positiven effekt :D


    werde es mal beobachten

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf

  • Das hört sich gut an. Auch wenn ich mir das momentan nicht erklären kann. Der LiveBuffer macht nichts anderes als die angegeben Zeitspanne zu warten, nachdem die ersten Daten bei Streamdev angekommen sind.


    Hat einer von euch die Möglichkeit zu prüfen, ob die ChannelChange-Funktion überhaupt benötigt wird oder ob die kleine Verzögerung alleine auch schon genügt (sprich: Inhalt der ChannelChange-Funktion auskommentieren)?

  • Hallo,


    ich sehe im Verhalten bei dieser Version keinen Unterschied.
    Den LiveBuffer auf 50ms stellen hilft in der Tat ein klein wenig (das Problem tritt nicht mehr ganz so häufig auf). Dazu braucht es aber nicht wirklich die ChannelChange Funktion oder?


    FYI: Mit dem XVDR-Plugin und XBMC tritt das Problem nicht auf. Da wird jeder Kanal geschalten, wo das bestimmte Plugin benötigt wird.

  • Ich muss nach dem ich nun noch ein paar Tage getestet habe meinen Vorrednern zustimmen. Das erhöhen des Live Buffers verbesserte zwar das Senderansprechverhalten aber nur bei den ersten Versuchen. Das eigentliche Verhalten das der ChannelChange Patch beheben soll kann ich mit Sat->IP nicht testen.
    Die eigentlichen Probleme die ich habe sind aber ersteinmal Sat->IP, bevor dort die Umschalterei nicht sauber funktioniert (mit den bösen Plugins ist das Glückssache), egal ob streamdev oder vnsi mit Xbmc.


    Ich muss mal schauen, einen meiner Clients auf nur Streamdev umzustellen und dann das Verhalten nochmals beobachten.

    Gruß
    Frodo

  • Könnte mir mal jemand aus dem Log die "changing ...of channel ... from ... to ..." Meldungen posten?


    [EDIT]... und sind überhaupt "streamdev: channel ... changed" Meldungen im Log zu finden?[/EDIT]

  • Bin leider noch nicht dazu gekommen das Problem näher zu untersuchen.
    Aber ich glaube nicht dass es an geänderten Pids liegt. Weil dann müsste ja min. Jeder zweite Umschalt versuch funktionieren. Aber bei mir funktioniert fast nie die kanähle zu zappen. Http Streaming funktioniert funktioniert aber. Ich muss die Logs mal prüfen. Könnte es nich sein dass das entschlüsseln zu lang braucht und der Client dann aufgibt? Weil im Server Log füllt sich der Puffer bis 100% Client log hab ich noch nicht angeschaut.


    Mfg Thomas

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

  • Wenn's mit HTTP-Streaming funktioniert, könnte das sehr wohl an den PIDs liegen. Bei HTTP-(TS-)Streaming werden alle PIDs gestreamt. An den Streamdev-Client werden hingegen nur die PIDs übertragen, die der Client (!) anfordert. Darum wäre ich sehr interessiert an den besagten Log-Meldungen, um zu verstehen, was da überhaupt abgeht.

  • Brauchst du die Server Oder Client Logs
    Und muss Filter Streaming aktiviert werden?
    Dann schau ich heut am Abend mal.


    Mfg Thomas

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

  • Das Server-Log wäre das wichtigste (mit dem Default-Log-Level, also -l 3). Sollten sich nicht nur die CA-IDs sondern tatsächlich auch die PIDs ändern, wäre auch das Client-Log bei aktiviertem Filter-Streaming interessant. Andernfalls dürfte das Client-Log nichts relevantes hergeben.

  • HTTP-Streaming wenn es nicht funktioniert


    Nach dem dritten Versuch wurde ein Bild angezeigt

    Code
    Jul 02 20:31:00 tank vdr[25198]: [25398] streamdev-writer thread started (pid=25198, tid=25398, prio=high)
    Jul 02 20:31:00 tank vdr[25198]: [25399] streamdev-livestreaming thread started (pid=25198, tid=25399, prio=high)
    Jul 02 20:31:00 tank vdr[25198]: [25400] receiver on device 1 thread started (pid=25198, tid=25400, prio=high)
    Jul 02 20:31:00 tank vdr[25198]: [25401] TS buffer on device 1 thread started (pid=25198, tid=25401, prio=high)

    2 Mal editiert, zuletzt von Dirk () aus folgendem Grund: Forenregeln

  • Hab jetz mal mitgelogt bei mir funktioniert so gut wie kein Tuning vom Client auf verschlüsselte Sender.


    Orf hat funktioniert: (Serer war aber auf Puls4)



    Sky Cinema funktioniert nicht:



    Sky Cinema +1 funktioniert nicht:



    Sky Cinema +24 Funktioniert nicht:




    Am Client mit rpihddevice kommen Meldungen wie:
    rpihddevice: audio parser skipped 2999 of 3001 bytes
    oder:
    ERROR: TS packet not accepted in Transfer Mode


    Dann Habe ich versucht am Server auf einen der nicht funktionierenten Sender zu schalten und dann klappte das Tuning für mehrere Sender. Ohne am Server zu Tunen war es am Client unmöglich auf den Kanal zu schalten. Das habe ich bei mehreren Kanälen getestet und es liesen sich ca. 5 - 10 Kanäle Tunen.
    Hir ist das Log dafür:



    Aber es kamen eigentlich nie relevante Pid änderungen wie man oben in dem Log sieht.
    Und die ChannelChange Funktion habe ich in den Logs auch nie gesehen.


    Hoffe das hilft ein bischen.


    mfg Thomas

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

    Einmal editiert, zuletzt von Dirk () aus folgendem Grund: Forenregeln

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!