vdr

vdr@linuxtv.org

2 participants
6731 discussions

Failing to tune in Freeview HD channels
by Chris Rankin 13 Aug '11

13 Aug '11

Hi, My 209e has arrived and is giving me all the normal Freeview channels. However, I'm unable to tune it into the HD ones. According to this site, the HD channels are all available on a separate MUX: http://www.ukfree.tv/txdetail.php?a=TQ339712 256QAM 32k 2/3 40Mb/s DVB-T2 MPEG4 50 BBC One HD (UK service without regions), 51 ITV 1 HD (ITV London), 52 Channel 4 HD London ads, 54 BBC HD, • as a digital multiplex transmitted on frequency C31 (554.0MHz) So I tried adding a new line to the uk-CrystalPalace file from dvb-apps: T 554000000 8MHz 2/3 NONE QAM256 32k 1/32 NONE However, scandvb rejects the "32k" part and still refuses to tune in, although I do get the PIDs: 0x0000 0x4440: pmt_pid 0x0064 BBC -- BBC HD (running) 0x0000 0x44c4: pmt_pid 0x00c8 ITV -- ITV1 HD (running) 0x0000 0x4500: pmt_pid 0x012c CHANNEL FOUR -- Channel 4 HD (running) 0x0000 0x4484: pmt_pid 0x19c8 BBC -- BBC One HD (running) So it looks like I'm going to have to create entries in my channels.conf file manually. Does anyone have a working one that s/he could share, please? Thanks, Chris

1 0

Default Audio Track
by Dominic Evans 13 Aug '11

13 Aug '11

A number of UK HD channels have the 'audio description' track as the first audio track in the stream e.g., Stream #0.0[0x201]: Video: h264 (Main), yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 56.55 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0x281](NAR): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s Stream #0.2[0x295](eng): Audio: ac3, 48000 Hz, 5.1, s16, 384 kb/s When playing back in VDR frontend it always just defaults to the first audio track in the stream, requiring a switch each time. Is it possible to make VDR default to automatically pick the highest quality (e.g. 5.1 > stereo) local-language tagged audio track?

2 2

UK FreeviewHD and VDR
by Chris Rankin 12 Aug '11

12 Aug '11

> I haven't pushed it upstream to Klaus, I think the preferable solution > is to do it as a plugin - search for the eepg plugin which incorporates > the parsing code. OK, thanks. Fedora 15 is still using VDR 1.6.x but the plugin looks small enough that I'm hoping it will work anyway :-). BTW, I see that eepg.c is using sscanf() with GNU-specific "%a[range]" tokens. Wouldn't it be more practical to use "%m[range]" tokens instead, c.f. the man page for sscanf from glibc: Since version 2.7, glibc also provides the m modifier for the same pur‐ pose as the a modifier. The m modifier has the following advantages: * It may also be applied to %c conversion specifiers (e.g., %3mc). * It avoids ambiguity with respect to the %a floating-point conversion specifier (and is unaffected by gcc -std=c99 etc.) * It is specified in the upcoming revision of the POSIX.1 standard. Cheers, Chris

2 1

UK FreeviewHD and VDR
by Chris Rankin 12 Aug '11

12 Aug '11

Hi, I currently use VDR to watch Freeview in the UK, and it works great with a Hauppauge NOVA-T-USB2 adapter. However, this adapter isn't compatible with DVB-T2 and so I've now ordered a nanoStick T2 290e and have upgraded to the Linux 3.0.1 kernel in eager anticipation. My ultimate goal is to use VDR to watch FreeviewHD, exactly as I've already been using it to watch Freeview, except that I understand that the EPG for the HD channels has been compressed using proprietary Huffman tables. I've already found this web site: http://www.rst38.org.uk/vdr/ The patch here for VDR (with separate "drop in" files freesat.t1 and freesat.t2) looks interesting, and would seem to allow VDR to read the compressed EPG in a transparent way. However, it has obviously not been merged to VDR in over 2 years, which would suggest that the VDR developers have rejected it for some reason. Could someone tell me what the "recommended" approach is for parsing a Huffman-compressed EPG with VDR please? I suspect that I can integrate this patch into VDR manually, but this isn't a viable long-term solution. Thanks for any advice, Cheers, Chris P.S. Yes, I know that I am assuming that FreeSat and FreeviewHD are using the same proprietary Huffman tables. But I'm also under the impression that this assumption is not a bad one.

8 9

Re: [vdr] UK FreeviewHD and VDR
by Gerald Dachs 12 Aug '11

12 Aug '11

> On 12 August 2011 12:33, Gerald Dachs <vdr(a)dachsweb.de> wrote: >> Currently I am testing vtuner on a Seagate Dockstar with 2 sundtek DVB-C USB sticks that is streaming to a Zotac HD-ID 40. It is promising. > > FYI vtuner is available here http://code.google.com/p/vtuner/ And here for Ubuntu Natty https://launchpad.net/~yavdr/+archive/unstable-vdr/ And in this dockstar repository: deb http://dockstar.yavdr.org unstable/ deb-src http://dockstar.yavdr.org unstable/ Currently I am working here on a version that uses memory mapping between client and kernel module that needs much less cpu: https://github.com/gdachs/vtuner. I want to simplify the client even more but I am not ready. Gerald

1 0

Re: [vdr] AAC LATM audio issue on dvb-t israeli service
by Barak Nahari 12 Aug '11

12 Aug '11

Sorry for repost, I've left out a line: On windows i've looked into the vlc log and found no error except the start of the stream. when initializing the dvb-t card but none so ever after except once in a while "warning late picture skipped (19199 -807)"

1 0

Re: [vdr] AAC LATM audio issue on dvb-t israeli service
by Barak Nahari 12 Aug '11

12 Aug '11

I've been done more testing to understand where's the problem. I've suspected that vlc on windows doesn't save the original ts as it is but remove errors from the stream, so i can't use it to analyze the problem. I'd like to emphasize that i can watch the stream on vlc both in windows os and linux. On linux i'm getting allot of ts continuity errors with all the tools i've tried (vdr, mumudvb, tvheadend, vlc), i had to understand where's it come from, is it the linux driver fault, the usb dongle or the ts is broadcast with errors. I've checked this with both it9135 and af9015 based usb dongle's, I believe these are the most popular chips used today so that can't be the problem. On windows i've looked into the vlc log and found no error except the start of the stream. when initializing the dvb-t card but none so ever after except once in a while I've used tsreader to save a mpg contains the whole stream as it is. http://www.2shared.com/video/mjpw6vqE/test12.html I would appreciated anyone's help analyzing the stream and i would like your opinion if it possible for a patch to be applied to vdr to demux (the right term?) the stream correctly. I'm aware that vdr can't be changed for every misconfigured ts but maybe can be less sensitive. Regard, Barak

1 0

[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

PES packets sent to cDevice::PlayVideo: only audio and video?
by Laz 07 Aug '11

07 Aug '11

Hi, I'm tidying up changes made to the softdevice plugin to get it working with vdr > 1.7.0 which uses TS for recordings. It all works fine pretty much most of but I have some errors I'd like to track down. Are the PES packets provided to the primary device's PlayVideo function purely video and audio packets? It looks to me like the PAT and PMT are stripped out so that only MPEG2 (no HD for me at the moment) audio and video packets should get to PlayVideo(), and so the primary device should play _all_ packets sent to it. Is this correct? I'm getting quite a few errors from avcodec complaining that decoded video frames have width and height set to 0. This tends to be at the start of a stream, i.e. on channel changing or starting playback. Are there any packets sent which don't contain any "playable" data that I need to test for and handle? Maybe I should bite the bullet and implement a decoder for PlayTsVideo()..! Cheers, Laz

2 3

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr