[Announce] streamdev 0.5.2

schmirl · May 12, 2012 at 4:41 PM

Hi,

ich habe heute unter http://projects.vdr-developer.org/projects/plg-streamdev/files Version 0.5.2 von streamdev für VDR 1.6 und 1.7 veröffentlicht.

Außerdem habe ich eine Reihe Änderungen ins GIT geschoben. Dazu möchte ich auf den Thread Testversion Streamdev-Server ab VDR 1.7.27 verweisen. Die GIT Version setzt jetzt VDR 1.7.25 (besser 1.7.27) voraus.

Changelog streamdev-0.5.2

- Use fileno() to retrieve the fd from a FILE structure (submitted by an
anonymous user)
- New special meaning "show current channel" when channel 0 is requested.
Applies to HTTP streaming only (thanks to Rolf Ahrenberg)
- Added streamdev-client support for upcoming streamdev-server versions
with purely priority driven precedence.
- API change of VDR 1.7.26: "avoid device" is no longer available
- Fixed ProvidesChannel() on client always returning true since the new timeout
option has been added.
- Updated Finnish translation (thanks to Rolf Ahrenberg)
- With VDR 1.7.25 priorities down to -99 will be used. Please update
"Minimum Priority" in streamdev-client setup.
- Use the new streamdev-client setup option "Live TV Priority" to control
precedence among multiple clients. The VDR option "Primary Limit" which
has previouly been used for this purpose has been dropped in VDR 1.7.25.
- Timout for network operations now configurable in streamdev-client setup
- Added timeout to Connect()
- Report the server-side HTTP status "503 Service unavailable" instead of
the client-side error "409 Conflict" when a channel is unavailable
(suggested by Methodus)
- Update of po headers and Finnish translation (thanks to Rolf Ahrenberg)
- support for non-cycle-free setups (e.g. where two VDRs mutually share
their DVB cards through streamdev-client/-server). Must be enabled in
streamdev-server setup. Obsoletes recursion patches.
- API change of VDR 1.7.22
- VDR 1.7.22 obsoletes cap_net_raw patch. Added cap_net_raw patch for VDR
1.7.5 - 1.7.21.
- Update and UTF-8 conversion of Finnish po files (thanks to Rolf Ahrenberg)
- Added "Hide mainmenu entry" option on server (thanks to Rolf Ahrenberg)
- Added server menu with list of clients. Connections can be terminated
with the "red" key. The former main menu action of suspending live TV
moved to the "blue" key.
- code cleanup and optimization (thanks to Ville Skyttä)
- properly shutdown IGMP timeout handler thread when the plugin is stopped.
Fixes occasional segfaults on VDR exit.
- fixed memory leak in libdvbmpeg read_pes (thanks to Ville Skyttä)
- dropped several unused functions in libdvbmpeg
- restricted VTP command RENR to liemikuutio patch < 1.32. Build fails with
newer versions of this patch (thanks to Ville Skyttä)
- updated outdated COPYING file and FSF address (thanks to Ville Skyttä)
- include SDT and TDT in TS streams
- the icy-name HTTP header sent with radio streams makes VLC pick the wrong
demuxer. Send icy-name only for ES audio streams.
- fixed regression of "live TV must be switched in VDR main thread" change:
deadlock in IGMP streaming server when switching live TV.
- streamdev-client returns true in its AvoidRecording() method introduced
with VDR 1.7.19. Note however that the impact of NumProvidedSystems is
higher.
- updated device selection to code of VDR 1.7.19
- adaption to VDR 1.7.12 cReceiver API change
- increased WRITERBUFSIZE. Has been reported to fix some ringbuffer
overflows (thanks to Luboš Doležel)
- check availability of channel if VTP command TUNE is called without
prior PROV call (e.g. client side EPG scan)
- added support for VDR 1.7.19 SignalStrength/SignalQuality
- analog video channels use the same transponder and pid for different
channels, so streamdev-client must always issue TUNE command
- server must close the VTP connection also if filter stream is broken
- fixed missing #ifdefs for new NumProvidedSystems setup option
- new externremux.sh mencoder config options: audio pid by language code
(-alang) and verbosity (-msglevel) (thanks to Pekko Tiitto)
- writer must not spend too much time waiting in select() without checking
if the thread has been cancelled
- added Spanish translation (thanks to Javier Bradineras)
- live TV must be switched in VDR main thread
- dropped compatibility with VDR < 1.5.16
- return value of streamdev-clients cDevice::NumProvidedSystems() now
configurable in plugin setup

pixelpeter · May 17, 2012 at 6:02 PM

Hallo Schmirl,

Funktioniert nur habe ich auf manchen Kanälen dies hier:

May 17 17:59:02 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 17:59:02 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 17:59:13 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 17:59:13 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 17:59:25 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 17:59:25 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 17:59:36 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 17:59:36 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 17:59:45 vdr1 vdr: video: 17:20:21.734 +65 359 240/\ms 12 v-buf
May 17 17:59:47 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 17:59:47 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 17:59:59 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 17:59:59 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:00:10 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:00:10 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:00:13 vdr1 vdr: [5448] changing name of channel 129 from '443 - 16:30,;' to '443 - 18:30,;'
May 17 18:00:14 vdr1 vdr: [5448] linking channel 919 from 102 649 722 723 724 to 649 722 723 724
May 17 18:00:22 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:00:22 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:00:33 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:00:33 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:00:45 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:00:45 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:00:45 vdr1 vdr: video: 17:21:21.734 +56 421 240/\ms 12 v-buf
May 17 18:00:56 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:00:56 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:01:07 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:01:07 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes
May 17 18:01:19 vdr1 vdr: [5454] ERROR: Streamdev: Section handler buffer overflow (70 bytes lost)
May 17 18:01:19 vdr1 vdr: [5454] cStreamdevFilter::Reset skipping 4026 bytes

man kann allerdings nichts sehen.

Peter

Torsten73 · May 17, 2012 at 11:23 PM

Quote from schmirl

- support for non-cycle-free setups (e.g. where two VDRs mutually share
their DVB cards through streamdev-client/-server). Must be enabled in
streamdev-server setup. Obsoletes recursion patches.

Verstehe ich das richtig, dass damit man nun 2 Receiver gleichzeitig als Server&Client miteinander verbinden kann?

schmirl · May 18, 2012 at 12:51 PM

pixelpeter:
kann ich mir momentan keinen Reim darauf machen. Beginnt das unmittelbar beim Umschalten auf einen der fraglichen Kanäle oder erst später? Sporadisch oder reproduzierbar bei immer den gleichen Kanälen (bei letzterem: Mit Gemeinsamkeiten?). Hast Du nur streamdev aktualisiert oder auch VDR und andere Plugins? Welche Streamdev-Version lief zuvor (bei einer GIT-Version: was war der aktuellste Eintrag in der HISTORY)?

torsten 73:

Quote

Verstehe ich das richtig, dass damit man nun 2 Receiver gleichzeitig als Server&Client miteinander verbinden kann?

Das ging schon lange - früher aber nur mit Patch. Jetzt auch ohne.

CKone · May 20, 2012 at 7:41 PM

ich hab irgendwie Probleme mit der neuen Version, eingesetzt als PIP mit ner 2ten vdr Instanz die auf der Hauptinstanz sitzt.

Und zwar hab ich das Problem nur auf der Maschine mit nur einer Sat Karte: hier verursacht ein hochzappen im Pip (Client) um einen Kanal das die Ausgabe des Servers mitschaltet. Ihm quasi das PIP aufzwingt. Früher war das so, dass der Client beim hochscahlten auf den nächsten Kanal der channels.conf auf dem selben Transponder gesprungen ist, also RTL HD auf Super RTL HD zum Beispiel. Somit hat die Anforderung des Servers vorrang gehabt.

Was muss ich nun wo an der neuen Version einstellen damit er den auf dem Server eingestellten Kanal wie vorher in Ruhe lässt?

Auf dem System mit 3 Karten tut es selbstredend wie immer hervorragend.

Christian

schmirl · May 21, 2012 at 8:44 AM

Ich vermute mal auf dem Server läuft mind. VDR 1.7.25, auf Server und Client streamdev 0.5.2? In diesem Fall musst Du im Client-Setup den Parameter "Live TV Priorität" auf einen negativen Wert setzen.

CKone · May 21, 2012 at 9:15 AM

jau, 1.7.27, das selbe binary 2x gestartet.

Hatte vermutet das es mit dem neuen Parameter zusammen hängt, der default Wert scheint nicht für dieses Usecase zu sein: hast du evtl die Linie für die setup.conf, sonst muss ich extra ein OSD auf dem Client einrichten um es einzustellen?

Danke
Christian

schmirl · May 21, 2012 at 12:58 PM

Jetzt steh' ich doch auf dem Schlauch. Es läuft streamdev-0.5.2 und nicht streamdev-0.5.2.git? Und im Streamdev-Server-Setup steht das Pausierverhalten auf "anbieten" oder "immer pausiert"? In diesem Fall sollte keine Umkonfiguration notwendig sein. Da würde mich das Debug-Log des Servers interessieren.

In streamdev-0.5.2.git gibt's das Pausierverhalten im Server-Setup nicht mehr. Dann muss in die setup.conf des Clients "streamdev-client.LivePriority = -1" (oder ein anderer negativer Wert) rein.

CKone · May 21, 2012 at 1:01 PM

here we go

root@CKtwo:/usr/local/src/devel/vdr# dpkg -l | grep streamdev

Code

ii  vdr-plugin-streamdev-client                0.5.2+git20120512.1506-0yavdr0~precise                          VDR Plugin to stream Live-TV to other VDR's - client part
ii  vdr-plugin-streamdev-server                0.5.2+git20120512.1506-0yavdr0~precise                          VDR Plugin to stream Live-TV to other VDR's - server part

root@CKtwo:/var/lib/vdr-pip# cat setup.conf | grep stream

Code

streamdev-client.HideMenuEntry = 0
streamdev-client.MaxPriority = 99
streamdev-client.MinPriority = -1
streamdev-client.RemoteIp = 127.0.0.1
streamdev-client.RemotePort = 2004
streamdev-client.StartClient = 1
streamdev-client.StreamFilters = 0

hilft das bei der Lösung?

Christian

CKone · May 21, 2012 at 1:09 PM

Code

"streamdev-client.LivePriority = -1"

funktioniert aber jetzt, danke das wars!

wenn Server auf RTL HD bleibt er jetzt da wenn der Client versucht den Transponder zu wechseln, schaltet also mit channelup zwischen RTL HD, RTL2 HD und Super RTL HD und greift nicht durch auf den Hauptvdr

Christian

schmirl · May 21, 2012 at 1:17 PM

Offenbar eine GIT-Version auf aktuellstem Stand. Damit gehört das "streamdev-client.LivePriority = -1" in die setup.conf.

Um andere Leser des Threads nicht zu verwirren: Wer das Tar-Archiv vdr-streamdev-0.5.2.tgz von der Streamdev-Homepage nutzt, bekommt Version 0.5.2. Da muss in der Regel nichts umkonfiguriert werden.

CKone · May 21, 2012 at 1:19 PM

Quote from schmirl

Offenbar eine GIT-Version auf aktuellstem Stand.

ist halt yavdr

Christian

schmirl · May 21, 2012 at 1:22 PM

Bin ja froh, dass auf diese Weise der veränderte Streamdev-Code von einer größeren Benutzerbasis getestet wird. Da muss ich die Tage wohl gleich nochmal 'was ins GIT schieben

hepi · May 21, 2012 at 1:41 PM

Naja gut, ich muss jetzt mal ein bisschen schmirl in Schutz nehmen. Er hat Version 0.5.2 released und sich die Finger wund geschrieben, was es da an neuen Features gibt. Seine Quality-Mitarbeiter haben wochenlang die streamdev 0.5.2 auf Bugs getestet und dann freigegeben.

Die Bugreports hier im Thread beziehen sich dann aber gar nicht auf die 0.5.2, sondern auf den aktuellen Dev-Stand. Kein Wunder, wenn ein Entwickler sich dann unter Druck gesetzt vorkommt...

Das yaVDR-Team kann aber auch wieder nix dafür, dass wir in unseren unstable-Repos und testing-Repos ein Paket 0.5.2+git20120512.1506-0yavdr0~precise (für Ubuntu Precise) haben, welches kein (!) Bestandteil irgendeiner veröffentlichten (stable) yaVDR-Version ist. Jeder kann natürlich dieses Paket verwenden, nur obliegt es dann eigentlich dem Nutzer allein, zu beurteilen, ob es sich um eine stable-Version eines Plugins handelt oder um den neuesten git-Stand. Wie auch immer, es klingt ja so, als würde es Probleme lösen. Dann ist es ja gut!

Gruß
hepi

CKone · May 21, 2012 at 1:58 PM

Sorry wenn ich hier jemandem zu nahe getreten bin, ich kann gerne meine Post hier rausnehmen oder sonst kannst du sie auch gern verschieben wenns das allgemeine Wohlbefinden stört...

Ich mein es ist mir JETZT schon klar das in diesem Fall hier GIT und release was signifikant anderes ist und das unter diesen Voraussetzungen ein separater Thread möglicherweise sinnvoller gewesen wäre, da gehst du aber normalerweise eher nicht von aus wenn release und git vom selben Tag sind.

schmirl · May 21, 2012 at 2:18 PM

Nur die Ruhe. Hat sich doch schnell aufgeklärt und alles funktioniert. Danke auch an hepi für die Richtigstellung, dass es sich um ein unstable/testing Paket handelt. Wollte nicht unterstellen, dass yaVDR experimentellen Code verteilt - sorry dafür.

In diesem Sinne

hepi · May 21, 2012 at 2:19 PM

Im VDR-Portal nehmen im Endeffekt sowieso viele Leute immer den neuesten Dev-Stand als Checkout zum Selber-Kompilieren (Gewohnheit: "das Neueste muss immer das Beste sein"), da haben es Leute mit richtiger, vernünftiger Release-Planung und Versionen schwer.
Viele Leute schreiben hier, sie haben von yaVDR 3.0 auf yaVDR 4.0 upgegradet, meinen aber von Version 0.3 zu 0.4. Wenn wir was mit "pre" im Namen veröffentlichen, um einen Alpha/Beta-Status anzudeuten, gibt es einige Leute, die denken, "pre" heißt soviel wie "premium". Ich habe mich hier nur zu Wort gemeldet, um vorzubeugen, dass schmirl sich vom yaVDR-Team gedrängt fühlt, seine Commits im Development Branch nicht mehr zu veröffentlichen.

Jetzt bin ich auch still.

Gruß
hepi

CKone · May 21, 2012 at 2:31 PM

nee, ohne sich jetzt gegenseitig anzuzicken und jetzt völlig OT zu werden, Hepi

wenn es so ist wie es ist das in den precise Zweig jetzt experimenteller Code gerutscht ist, selbiger aber (ich sag mal vorsichtig) demnächst in den nächsten stable Zweig rutschen soll, dann ist es doch streng genommen ein Fall für den yavdr Bugtracker?

Christian

hepi · May 21, 2012 at 2:43 PM

Quote from CKone

wenn es so ist wie es ist das in den precise Zweig jetzt experimenteller Code gerutscht ist, selbiger aber (ich sag mal vorsichtig) demnächst in den nächsten stable Zweig rutschen soll, dann ist es doch streng genommen ein Fall für den yavdr Bugtracker?

CKone, ich will Dich auch nicht anzicken, sorry, wenn es so rübergekommen ist. Es ist ja keine große Sache, wahrscheinlich habe ich in meiner wortreichen Art es überzogen formuliert.

Der Bugtracker ist eigentlich primär für Pakete aus den stable PPAs bzw. auch den testing PPAs, wenn wir um Feedback bitten. Ja, Du kannst deshalb durchaus ein Ticket da aufmachen. Die Precise-Pakete sind gerade in den letzten Tagen/Stunden von unstable nach testing gewandert. Ich habe beispielsweise gestern Abend beim Testen daheim gemerkt, dass irgendwas mit streamdev-server nicht stimmt, hatte aber noch keine Zeit, es genauer anzuschauen.

Gruß
hepi

[Announce] streamdev 0.5.2

Participate now!

Users Viewing This Thread