vdr July 2011

vdr@linuxtv.org

29 participants
35 discussions

Re: [vdr] Diseqc problems with VDR1.7.19
by Hawes, Mark 01 Sep '11

01 Sep '11

Just looked at the trace I sent in my initial post and realised that I had selected a Diseqc command that I had modified while trying to diagnose the situation so my annotations < > were a bit misleading. The following should be less confusing: Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250 [E1 31 6B 04] W15 T Diseqc action = 1 Diseqc action = 3 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 < Wrong, should be E0 10 38 F4 > Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 < Wrong, should be E0 31 6B 04 > Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Diseqc action = 2 Again, the final Diseqc command has been sent three times, not the three commands in the sequence they appear in the command list. Apologies for the confusion. Mark.

5 6

Can' read mkv with vdr-1.7.18 + mplayer + TT S2-6400 !
by Karim Afifi 17 Aug '11

17 Aug '11

Hello, Since I have upgraded my hardware from "TT Nexus" to "TT S2-6400", I can't read any mkv file anymore from my vdr-1.7.18 and MPlayer. It seems that VDR can't share the device. This limitation is very very annoying : Is there any patch for VDR and/or for MPlayer ? Do you know any workaround or any other solution ? Regards. Karim _______________________________________________________________ Here is the log : logger: *** DEBUG: MPLAYER_RETURN: "0" logger: *** DEBUG: parsed output for ORIG_X: "1280" logger: *** DEBUG: parsed output for ORIG_Y: "544" logger: *** DEBUG: parsed output for ORIG_FPS: "24.000" logger: *** DEBUG: parsed output for ORIG_ASPECT: "0.0000" logger: *** DEBUG: parsed output for VIDEO_FORMAT: "avc1" logger: *** DEBUG: parsed output for AUDIO_CODEC: "ffdca" logger: *** INFO: Source Video has Resolution of 1280 x 544 ... logger: *** DEBUG: Film "" logger: *** DEBUG: Variable MAX_X has value "1024" logger: *** DEBUG: Variable NEW_Y has value "435" logger: *** INFO: For Sqare Pixels we would scale to 1024 x 435 ... logger: *** DEBUG: Variable XResTEMP has value "352 480 528 544 688 704 720" logger: *** DEBUG: Variable AnzahlVonXResTEMP has value "7" logger: *** DEBUG: Variable NEW_X has value "720" logger: *** DEBUG: setting REAL_Y = FULL_Y "" logger: *** DEBUG: Variable CMDLINE has value "/usr/bin/mplayer -vo mpegpes -ao mpegpes -vf scale=720:435,expand=720:576:-1:-1:1,lavc=5000:25 -speed 1.04 -framedrop -cache 8192 -slave -nolirc -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 -quiet " MPlayer 1.0rc4-4.5.2 (C) 2000-2010 MPlayer Team PLAYING /VIDEO/DIVX/fichier.mkv Cache fill: 0.00% (0 bytes) [mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0 [mkv] Track ID 2: audio (A_DTS) "French DTS 1509kbps", -aid 0, -alang fre [mkv] Will play video track 1. Matroska file format detected. VIDEO: [avc1] 1280x544 24bpp 24.000 fps 0.0 kbps ( 0.0 kbyte/s) Opening /dev/dvb/adapter0/video0+audio0 DVB VIDEO DEVICE: : Device or resource busy Error opening/initializing the selected video_out (-vo) device. =============== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [ffdca] afm: ffmpeg (FFmpeg DTS) =============== Opening /dev/dvb/adapter0/audio0 DVB AUDIO DEVICE: Device or resource busy Failed to initialize audio driver 'mpegpes' Could not open/initialize audio device -> no sound. Audio: no sound Video: no video

7 12

How to convert a JPEG image to an HD video frame?
by Klaus Schmidinger 14 Aug '11

14 Aug '11

The VDR plugin 'pictures' (part of the original VDR archive) uses a Perl script named 'pic2mpg', which converts a JPEG image into an MPEG frame that can be displayed directly by VDR's primary output device. This is done in essence by the command sequence jpegtopnm $Pict | pnmscale --xscale=$ScaleW --yscale=$ScaleH | pnmpad --black --width $SW --height $SH | ppmtoy4m -F $framerate -I p -S 420mpeg2 | mpeg2enc -f 3 -b 12500 -a $aspect -q 1 -n $system2 -o $Mpeg (see the actual script for the complete working environment). While this works fine for SD video, I can't seen to figure out how to make this work for an HD video output device. The video frame should be a 1080i frame in my case (my tv can't handle 1080p), but could optionally also be 720p or 1080p, depending on the actual tv's capabilities. Can anybody give me a pointer how this script could generate HD video frames? Klaus

4 8

[ANNOUNCE] VDR developer version 1.7.19
by Klaus Schmidinger 10 Aug '11

10 Aug '11

VDR developer version 1.7.19 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.19.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.18-1.7.19.diff MD5 checksums: 1eb04ecdc2b11ab8641ebfaa2cb93f42 vdr-1.7.19.tar.bz2 db16ce7bb51e0db837ed56ef4744a67e vdr-1.7.18-1.7.19.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version introduces functions to determine the "signal strength" and "signal quality" through cDevice. If you are using a DVB card that contains an stb0899 frontend chip (like the TT-budget S2-3200) you may want to apply the patches from ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches to the LinuxDVB driver source in order to receive useful results from that frontend. Since apparently the various frontend drivers return different maximum values in their FE_READ_SIGNAL_STRENGTH and FE_READ_SNR functions (some deliver a value in the range 0x0000...0xFFFF, while others return values as "dB/10" or "dBm/10" (the latter with an offset to make the value positive, since the parameter is unsigned), the functions cDvbTuner::GetSignalStrength() and cDvbTuner::GetSignalQuality() use the device's "subsystem ID" to map these values into the range 0...100, which is the normalized return value of these functions. Take a look at these two functions and maybe remove the comment characters from the lines //#define DEBUG_SIGNALSTRENGTH //#define DEBUG_SIGNALQUALITY in dvbdevice.c to get some debug output if your device doesn't return any directly useful values and may have to be added appropriately to the 'switch (subsystemId)' statement. The channel display of the 'sttng' skin uses these values to implement a signal strength/quality display. The changes since version 1.7.18: - Fixed cString's operator=(const char *String) in case the given string is the same as the existing one (thanks to Dirk Leber). - Avoiding a gcc 4.6 compiler error in the skincurses plugin (thanks to Tobias Grimm). - TsGetPayload() now checks if there actually is a payload in the given TS packet (reported by Dirk Leber). - Now sorting the source file names in the call to xgettext, to make sure the results are not dependent on the sequence of the files. Plugin authors may want to change the line containing the xgettext call in their Makefile accordingly by changing "$^" to "`ls $^`". - The primary device is now only avoided for recording if it is an old SD full featured card. This is done through the new function cDevice::AvoidRecording(). - Subtitle PIDs are now also decrypted (thanks to Reinhard Nissl). - Fixed a possible race condition in cDiseqc::Execute() (reported by Marco Göbenich). The return value of cDiseqcs::Get() is now const, so plugin authors may need to adjust their code if they use this function. - The new functions cDevice::SignalStrength() and cDevice::SignalQuality() can be used to determine the signal strength and quality of a given device (thanks to Rolf Ahrenberg for some input on how to use BER and UNC values to generate a "quality" value). - The 'sttng' skin now displays two colored bars at the bottom of the channel display, indicating the strength (upper bar) and quality (lower bar) of the received signal. The number to the left of these bars indicates the actual device the current channel is being received with. - Fixed detecting frames in case the Picture Start Code or Access Unit Delimiter extends over TS packet boundaries (reported by Johan Andersson). In order to fix this, the semantics of cFrameDetector had to be changed a little. See cRecorder::Action() and cIndexFileGenerator::Action() on how to use the new cFrameDetector::NewPayload() function. - The frame detector now only starts collecting PTS values after it has seen the first I-frame, otherwise it might get MaxPtsValues values and stop analyzing even though the incoming data is still garbage (reported by Derek Kelly). - The info file of a recording is now only overwritten with a new fps value if that new value is not the default value (thanks to Derek Kelly for reporting a problem with the fps value being overwritten in case a recording was interrupted and resumed, and the fps value could not be determined after resuming recording). - The initial channel is now stored by the channel ID in the setup.conf file, in order to avoid problems in case channels are reordered or deleted (reported by Lars Bläser). - Added support for "content identifier descriptor" and "default authority descriptor" to 'libsi' (thanks to Dave Pickles). Have fun! Klaus

5 11

VPS fallback patch
by Dave 06 Aug '11

06 Aug '11

For some time (at least since 2008) Mandriva Linux have been including the attached patch in the version of vdr shipped with their distribution. It allows timers to be triggered directly by the Now/Next data in the EIT provided that a new parameter is set in the config file. Looking back in the mailing list archives I see the question of including this feature in vdr is an old one; see for example: http://www.linuxtv.org/pipermail/vdr/2005-August/003975.html However I wonder if the time is now right to reconsider? In the UK an accurate Now & Next EIT is provided on DVB-T as part of the Freeview Plus (aka TV- Anytime) service, with the data being directly derived from the broadcasters' playout systems. I have been running vdr with this patch for two years and have never missed a recording due to incorrect information. It was really useful during the recent Wimbledon tournament when many programmes ran late due to live coverage of the tennis. Dave

4 6

Transfer mode vs TS playback: any difference in TS streams for vdr.1.7.19?
by Laz 06 Aug '11

06 Aug '11

Hi, I'm currently updating the softdevice plugin to work with the changes to TS format that started with vdr-1.7.1 and also current versions of ffmpeg (libavcodec does the actual decoding). I've made some progress with vdr-1.7.19: Old PES recordings play fine (as I'd hoped they would!) New TS recordings play: the video looks fine. PlayTSVideo convertes to PES and passes that to PlayVideo of the output device (I assume it would be relatively straightforward to implement a proper PlayTs using avcodec but that's for a later date!). The sound is totally messed up: just lots of random buzzing noises (not looked into the audio yet). Tranfer mode does not work at all, all I get is a black screen and silence. Before I dig into buffers, etc., is there any difference between the streams sent to PlayTS in transfer mode and in playback? I see that transfer mode generates a PAT/PMT on the fly and passes the stream directly to PlayTs. Does a similar thing happen to a recording, i.e. the PAT/PMT is added before writing to disk and then the stream sent during playback is identical to that which would have been sent if it had been watched in transfer mode? Does the output device ulitimately receive the same set of PES packets? Thanks, Laz

3 5

Re: [vdr] HDHomerun and streamdev
by Kirk Bromfield 03 Aug '11

03 Aug '11

I had the same problem until I downgraded to streamdev 0.5.0 and hdhomerun_atsc_firmware_20100828.bin. I am not sure both of these changes are necessary as I changed both at the same time. :( http://download.silicondust.com/hdhomerun/hdhomerun_atsc_firmware_20100828.… On Jul 16, 2011 6:00 AM, <vdr-request(a)linuxtv.org> wrote:

3 5

Re: [vdr] VDR Issues with DVB-T Services in Israel
by Barak Nahari 30 Jul '11

30 Jul '11

I've been looking in my syslog, http://pastebin.com/L3MmV7dh and found a segfault error, is it concerning xine decoding of the h264 stream? >From a quick googling it looks like this may be the problem. Is there's a way do get debug info from vdr and maybe to determine where the fault? When trying to play the stream i captured with vlc in mplayer i only get sound, is anyone can confirm that there is a problem while decoding the stream. My stream capture http://www.2shared.com/file/wEdFKfZy/test.html If so then will vdr remain unusable at all until a fix is patched to xine lib.

2 2

Different handling of back / menu keys
by Torgeir Veimo 30 Jul '11

30 Jul '11

The VDR menu key is somewhat under-utilised, it only toggles the menu on and off, I think it would be an improvement if it was combined with the back key. Instead of using the menu key to toggle the menu on and off, it could trigger the osd menu initially, initially, but would then subsequently work as a back key. So if you're deep in a menu, and you press the menu key, it would take you back one level, just as the back key does. If you need to go fully out, you long-press the menu key. This would mostly eliminate the need for a dedicated back key, and would simplify the basic menu navigation and make it more in line with other menu navigation systems (eg the ipod comes to mind). -- -Tor

2 1

projects.vdr-developer.org now has a new home
by Tobi 29 Jul '11

29 Jul '11

Hello everyone! http://projects.vdr-developer.org/news/135 projects.vdr-developer.org is now hosted on a new server: Opteron™ 1381 Quad-Core, 4 x 2,5 GHz 4 GB RAM 2 x 500 GB (Raid 1) 500 GB FTP Backup Space IP: 85.214.78.111 The server is still fully sponsored by xeatre.tv (http://www.xeatre.tv). Thanks a lot! Thanks to Siegmar as well for providing the subdomain! It's currently running a 64bit Debian/Squeeze with Kernel 2.6.32-5. I also took the chance to change some things under the hood. The updated Redmine now runs under a Mongrel cluster served by the Nginx webserver. This should give it a minor performance boost. git-web has been replaced by cgit, which is significantly faster. You might now also use the cgit-URL's to pull a repository via http. (http://projects.vdr-developer.org/git) Instead of gitosis, I now use gitolite to manage the Git-repositories. I have plans to integrate the repository and public key management into Redmine at some time, but don't expect this very soon. The username for SSH-write-access to the Git-repositories has been changed from 'gitosis' to 'git-vdr'. You can still continue to use the old username, but I might drop this sometimes. It is easily changed with: git remote set-url origin \ git-vdr(a)projects.vdr-developer.org:<repository-name>.git If you are missing a feature, have any improvement suggestions or have any problem, please create an issue here: http://projects.vdr-developer.org/projects/project-management/issues/new or contact me by mail: pvdo(a)e-tobi.net I'm still fine-tuning everything and try to make projects.vdr-developer.org as secure and reliable as possible. So if the site isn't reachable in the next days for a short time, I might currently be working on it. Please try again later in this case or contact me. Have fun! Tobias

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr July 2011