vdr January 2009

vdr@linuxtv.org

113 participants
107 discussions

Small VDR-streamdev patch for Popcorn Hour NMT
by jori.hamalainen＠teliasonera.com 10 Feb '09

10 Feb '09

Hi, directly Popcorn cannot stream from vdr-streamdev because streamdev server does not provide necessary info by default. I used 0.3.4 as a basis - I believe this patch would work for 0.4 without modification. With this patch I've been able to stream SD stuff. Need more investigating for HD H.264 stuff, I can hear sound but no picture. More info about NMT (Networked media tank) devices etc: http://www.networkedmediatank.com/wiki/index.php/Main_Page What is done on this patch: - Add remote control shortcuts (red, green, yellow and blue) to select wanted stream format (Yellow worked for me with PCH) - Added automated audio track selection to default URL (+1) - Added suffix for URL (TS w/ "C-123-123-123.ts or S-12-123-123.ts", ".ps", ".vdr" for PES and ".mpeg" for ES, extern no suffix) - Added 5000000 bytes prebuf-tag to shorten prebuffer time - Added remove control shortcut for selecting channels (channel number < 1000) - Added "vod" tag for PCH to recognize "video-on-demand" These small enhancements are inside anchor tag and they do not affect other browsers, just MSP-compatible browsers - so in theory this patch could be built-in for streamdev. But naturally my vision is to have own GUI for MSP. But first need to verify that streaming works - and it does. Just some HD fix is needed. On PCH menu set Webservices URL: http://[your.VDR]:3000/PES/all.html (This should be the default - you can change formats easily with RGYB buttons) Actual web page is not beautiful compared what you can do with MSP plugins - but this is a start. Best regards, Jori ----------- vdr server # diff /usr/src/vdr/PLUGINS/src/streamdev/server/menuHTTP.c /usr/src/vdr_plugins/streamdev-0.3.4/server/menuHTTP.c 201c201 < (std::string) "[<a href=\"/TS/" + self + "\" TVID=\"RED\">TS</a>] "); --- > (std::string) "[<a href=\"/TS/" + self + "\">TS</a>] "); 203c203 < (std::string) "[<a href=\"/PS/" + self + "\" TVID=\"GREEN\">PS</a>] "); --- > (std::string) "[<a href=\"/PS/" + self + "\">PS</a>] "); 205c205 < (std::string) "[<a href=\"/PES/" + self + "\" TVID=\"YELLOW\">PES</a>] "); --- > (std::string) "[<a href=\"/PES/" + self + "\">PES</a>] "); 207c207 < (std::string) "[<a href=\"/ES/" + self + "\" TVID=\"BLUE\">ES</a>] "); --- > (std::string) "[<a href=\"/ES/" + self + "\">ES</a>] "); 339,349d338 < std::string suffix; < < switch (streamType) { < case stTS: suffix = (std::string) ".ts"; break; < case stPS: suffix = (std::string) ".ps"; break; < case stPES: suffix = (std::string) ".vdr"; break; < case stES: suffix = (std::string) ".mpeg"; break; < default: < case stExtern: suffix = (std::string) ""; break; < } < 351,357c340,341 < line += (std::string) "<A href=\"" + (std::string) current->GetChannelID().ToString() + "+1" + suffix + "\" vod prebuf=5000000"; < < if (current->Number() < 1000) { < line += " TVID=\"" + (std::string) (const char*) itoa(current->Number()) + "\""; < } < < line += (std::string) ">" + current->Name() + "</A>"; --- > line += (std::string) "<a href=\"" + (std::string) current->GetChannelID().ToString() + "\">" + > current->Name() + "</a>"; 370c354 < "+" + (const char*)itoa(index) + suffix + "\" class=\"apid\" vod>" + current->Alang(i) + "</a>"; --- > "+" + (const char*)itoa(index) + "\" class=\"apid\">" + current->Alang(i) + "</a>"; 374c358 < "+" + (const char*)itoa(index) + suffix + "\" class=\"dpid\" vod>" + current->Dlang(i) + "</a>"; --- > "+" + (const char*)itoa(index) + "\" class=\"dpid\">" + current->Dlang(i) + "</a>";

9 44

[ANNOUNCE] VDR developer version 1.7.4
by Klaus Schmidinger 08 Feb '09

08 Feb '09

VDR developer version 1.7.4 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.4.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.3-1.7.4.diff WARNING: ======== This is a *developer* version. Not even *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The main focus of this version is still the switch to Transport Stream (TS) as the recording format. There are still a few glitches, mainly - Recording files larger than 4GB or with more than 255 separate files hasn't been tested yet. - Recording h.264 broadcasts has been roughly verified to work, but no replaying of such recordings has been tested yet. DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!! THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT WORK WITH FUTURE VERSIONS! Despite this, I do hope there will be some people who can take a look at the changes and maybe test the new recording format - and report bugs or provide fixes ,-) IMPORTANT: ========== You need to patch your driver with ftp://ftp.cadsoft.de/vdr/Developer/av7110_ts_replay__1.diff in order to replay TS recordings with full featured DVB cards! Without this patch replaying and Transfer Mode with these cards will not be possible! The changes since version 1.7.3: - Removed the '#define FE_CAN_2ND_GEN_MODULATION', since it was wrong and the flag is now in the driver, anyway. - The full-featured DVB cards are now given the TS data directly for replay (thanks to Oliver Endriss for enhancing the av7110 driver to make it replay TS data). The patch from ftp://ftp.cadsoft.de/vdr/Developer/av7110_ts_replay__1.diff implements this change in the driver. The patch av7110_v4ldvb_api5_audiobuf_test_1.diff mentioned in version 1.7.2 is still necessary to avoid audio and video glitches on some channels. - Added a typecast in cUnbufferedFile::Write() to avoid an error message when compiling on 64 bit systems. - Added some missing 'const' statements to cBitmap (thanks to Andreas Regel). - Fixed returning complete PES packets in cTsToPes::GetPes() (thanks to Reinhard Nissl). - Added a missing Detach() in cTransfer::Activate() (thanks to Marco Schlüßler). - Added clearing the TS buffers in cDevice::Detach() (thanks to Marco Schlüßler). - Fixed incrementing the continuity counter in cPatPmtGenerator::GetPmt() (thanks to Johann Friedrichs). - Fixed removing deleted recordings in case there is a problem. Once a recording caused a problem with removing, no others were removed any more and an ongoing recording could fill up the disk and cause other recordings to be deleted automatically (reported by Reinhard Nissl). - Added "DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" to Make.config.template (thanks to Johann Friedrichs for pointing this out). Plugin authors should add this line to their Makefile or Make.config if they use file access functions that need special versions for 64 bit offsets. - The new command line option -i can be used to set an "instance id", which will be used to distinguish recordings of the same broadcast made by different instances of VDR (suggested by Frank Schmirler). This replaces the use of the "resume id" that was introduced in version 1.7.3. - Added checking mutexCurrentAudioTrack to cDevice::PlayTs() (thanks to Reinhard Nissl for pointing this out). - Fixed handling the pointer field in cPatPmtParser::ParsePmt() (thanks to Frank Schmirler - sorry I swapped two lines when adopting the original patch). - Checking the remaining packet length after processing the pointer field in cPatPmtParser::ParsePat() and cPatPmtParser::ParsePmt() (suggested by Frank Schmirler). - Checking the pointer field in cPatPmtParser::ParsePmt() only in 'payload start' packets (suggested by Frank Schmirler). - Changed cPatPmtGenerator to make sure the PMT pid doesn't collide with any of the actual pids of the channel. - Fixed cDevice::PlayTsAudio() and made cDevice::PlayTsVideo() return 0 if PlayVideo() didn't play anything. - Added an 'int' typecast to calculations involving FramesPerSecond() to avoid compiler warnings (reported by Winfried Koehler). - Fixed detecting frames for pure audio recordings. - Fixed editing PES recordings. The frame type in the index.vdr file generated for the edited PES recording is set to 1 for I-frames and 2 for all others (P- and B-frames). The exact frame type doesn't matter for VDR, it only needs to know if it's an I-frame or not. - The PAT/PMT is now only processed if its version changes (reported by Reinhard Nissl). - Fixed handling the maximum video file size (reported by Udo Richter). - Improved fast-forward/-rewind for audio recordings. The actual data is now sent to the output device, so that it can be replayed and thus cause the proper delay. For pure audio recordings the audio is no longer muted in fast-forward/-rewind mode, so that some orientation regarding the position within the recording is possible. There may still be some offset in the replay position displayed by the progress indicator when switching from fast-forward/-rewind to play mode, as well as in the current position during normal play mode. This is due to the various buffers between the player and the output device and will be addressed later. Note the new function cDevice::IsPlayingVideo(), which is used to inform the player whether there is video data in the currently replayed stream. If a derived cDevice class reimplements PlayTs() or PlayPes(), it also needs to make sure this new function works as expected. Have fun! Klaus

7 11

eHD and how subtitle timing start work
by Vesa 02 Feb '09

02 Feb '09

There has been several discussion about eHD dvb subtitle timing. Vdr works correctly on this area and time subtitles as they should be. Reelbox-plugin do not deliver timing info (STC) with default settings. The catch is soundcard support. For audio delay adjustment reelbox-plugin deliver STC. So just turn "Analog audio" to "Soundcard" and STC is delivered to VDR and subtitles are in time. Only issue after this is with replaying recording, it will took some time to get STC to correct value. For this it would be nice to get min and max value for subtitle delay. If delay is out of those limits, vdr would use middle setting. -- Vesa

4 5

mp3 plugin+cdfs
by Придворов Андрей 02 Feb '09

02 Feb '09

Hi The mp3 plugin have trouble when play audio cd with cdfs module It play disk fine, but if press "stop", vdr hangs and not responding for RC command, but continue play disk. After some minutes, play stop and vdr can normal works I think cause in plugin sound buffer. Attached patch helped me I only add flush() before delete player....

4 3

[ANNOUNCE] vdr-xine-0.9.0 plugin
by Reinhard Nissl 01 Feb '09

01 Feb '09

Hi, after being away 7 month from VDR development I'm pleased to announce release 0.9.0. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2009-01-12: Version 0.9.0 - Updated INSTALL and MANUAL accordingly. - Fixed several multithreading issues which got triggered on SMP systems (thanks to Edgar (gimli) Hucek for reporting issues and testing fixes). - Added support for VDR-1.7.3 besides TS still pictures. - Pulled patched VDR-1.7.2's remux.[ch] for a quick adaption to to VDR-1.7.3 (thanks to Klaus Schmidinger for his approval). - Fixed PTS handling in xine-lib's FFmpeg decoder for recent FFmpeg versions which should provide better A/V sync now. - Added patch sets to input_vdr.c which allow to omit parts of the MRL, e. g. vdr:// should be sufficient now (thanks to Ludwig Nussel for providing them). - Make use of new OSD functionality in xine-lib-1.2. For now an OSD implementation must provide both new features to have vdr-xine make use of it. - Extended OSD support in xine-lib-1.2 to allow truecolor OSDs as well as hardware scaled OSDs. The new functionality is currently only provided by VDPAU enabled installations. - Added frame grabbing support for accelerated frame formats to xine-lib. Previously, xine-lib exitted the app when frame grabbing was requested for accelerated frame formats like xxmc. You'll now get a green image in that case. Reading back the content of an accelerated frame is currently only provided by VDPAU enabled installations. - Hacked support for VDR-1.7.1's new cDevice::PlayTs() method. - Grab image nolonger needs pnmcut to select the relevant area of the TV image. Besides that, grab image respects the aspect ratio you select in VDR's setup menu, i. e. a 16:9 setup and a 16:9 broadcast will grab you a image without black borders. A mismatch of aspect ratios will add black borders to the image to match the visual impression you get on your TV set. Additionally, the grabbing of field pictures was corrected with regard to color upsampling. - A script mkNoSignal.sh is provided to create custom logos. Just provide PNG files named noSignal16x9*.png (and ...4x3... respectively) and have the tools mentioned in INSTALL in your path. You'll have to move your custom logos then over the default files. - The vdr-xine logo is now available in two aspect ratios (4:3 and 16:9) as more channels provide 16:9 content. Then vdr-xine selects the logo which matches VDR's DVB setup option video format. - Added the ability to detect discontinuities in live TV and to start a new buffering period in such a case. This will help to resume to fluent playback from bad weather conditions or when disconnecting and reattaching the antenna cable. - Updated it_IT.po (thanks to Diego Pierotto for providing the translations). Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

8 12

Disabling EPG update from air or shift it in time
by Alex Betis 01 Feb '09

01 Feb '09

Hi all, Is there any configuration that disables EPG updates received on the channel? Or is there a way to shift time of those updates before they are written to EPG.data? The problem is that I have some channels that are transmitted for different time zones that start transmitting EPG info, but looks like the EPG is not shifted. There are some other shifted channels that do transmit the EPG properly, so I believe that's a provider problem. I use s script that updates those channels from internet, so I don't mind to disable EPG update received on the channel. Thanks.

3 10

no channel update for certain channels
by Patrick Rother 01 Feb '09

01 Feb '09

On Tue Jan 27 11:03:39 CET 2009 Klaus Schmidinger wrote: > On 27.01.2009 11:01, Matthias Dahl wrote: > > On Tuesday 27 January 2009 10:37:24 Klaus Schmidinger wrote: > >> Have you tried contacting the broadcaster about this? > >> Such problems should be fixed at the root ;-) > > > > I agree. There is just one exception: it's done intentionally by > > the broadcaster to limit reception to certain boxes. :-} For > > those cases it would be nice to exclude those channels from the > > automatic update process. > > Those bastards... > > Can you give an example of such a channel? I am currently suffering from events like this: Jan 28 05:50:53 vdr vdr: [15232] changing pids of channel 84 from 2815+2815:2816=deu:0:32 to 2815+2815:2816=deu:0:0 Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 83 from 1535+1535:1536=deu:0:32 to 1535+1535:1536=deu:0:0 Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 82 from 1023+1023:1024=deu:0:32 to 1023+1023:1024=deu:0:0 Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 85 from 3071+3071:3072=deu:0:32 to 3071+3071:3072=deu:0:0 Jan 28 05:50:55 vdr vdr: [15232] changing pids of channel 81 from 1791+1791:1792=deu:0:32 to 1791+1791:1792=deu:0:0 Jan 28 05:50:55 vdr vdr: [15224] stopping recording due to modification of channel 83 Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 84 from 2815+2815:2816=deu:0:0 to 2815+2815:2816=deu:0:32 Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 83 from 1535+1535:1536=deu:0:0 to 1535+1535:1536=deu:0:32 Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 82 from 1023+1023:1024=deu:0:0 to 1023+1023:1024=deu:0:32 Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 85 from 3071+3071:3072=deu:0:0 to 3071+3071:3072=deu:0:32 Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 81 from 1791+1791:1792=deu:0:0 to 1791+1791:1792=deu:0:32 Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 75 from 2559+2559:2560=deu:0:0 to 2559+2559:2560=deu:0:32 Jan 28 05:52:45 vdr vdr: [15224] stopping recording due to modification of channel 83 Recording gets heavily fragmented and unviewable. I suggest that recordings shall not be stopped and restarted except when things are changed that are neccessary for the recording (which the TPID is not), and maybe there shall be even more rate limiting on PID updates for channels with active recordings on. Thank you.

2 4

32-bit capabilities?
by alex bustamante 31 Jan '09

31 Jan '09

"warning: `vdr' uses 32-bit capabilities (legacy support in use)" What is this exactly?

2 1

no channel update for certain channels
by Matthias Dahl 30 Jan '09

30 Jan '09

Hi. For certain situations, it'd be great to exclude some channels from the automatic channel update. For example, when one has entered a channel manually which broadcasts wrong channel informations. With the next channel update, all is overwritten. So one has to either completely disable the automatic updates or live without the channel for the time being. I had just a quick look over the vdr source and figured it wouldn't be too hard to come up with a patch to support something like this I guess. So I wanted to ask if this new feature would be considered ok for inclusion into vdr-1.7.x or if there are reasons against it? Otherwise I would put it on my todo list and get to it when I get some time... if no one else does it in the meantime that is. :-) Best regards, matthias.

4 14

Vdr 1.7.4 replay hangs, when subtitles start
by Timo Helkio 30 Jan '09

30 Jan '09

Hi all, Vdr-1.7.4 stops playing recordings with subtitles, when subtitles start and in the log is seen "subtitleConverter thread started". There are no other messages in the log and replay goes on if you press FF and play buttons again. I have a Nexus-s card as tv-output and this happens with "pure" Vdr, no patches and plugins installed. Timo

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr January 2009