vdr June 2019

vdr@linuxtv.org

6 participants
9 discussions

Trouble with DVB-T2 on frontend 1
by Marko Mäkelä 03 Jan '22

03 Jan '22

Hi all, I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends: /dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C) I guess it is similar to this one; just a slightly different plastic case with some more ventilation holes: http://blog.palosaari.fi/2014/09/naked-hardware-18-astrometa-amdvb-t2-v2.ht… The hardware appears to work fine, once I copied the /lib/firmware/dvb-demod-mn88473-01.fw from somewhere. The firmware upload has failed at least once on the Raspberry Pi 2 (using Linux 4.9.59), but never on another machine that runs a 4.13.0 kernel. I did not yet get the infrared remote control to produce anything in evtest. With dvbv5-zap (after running dvbv5-scan), I can tune into DVB-T2 channels like this: dvbv5-zap -a 0 -f 1 -c dvb_channel.conf 'Yle TV1 HD' -r After this, I can play the video and audio stream on the Raspberry Pi 2: omxplayer /dev/dvb/adapter0/dvr0 Unless I explicitly specify the options -a 0 -f 1, then dvbv5-zap will fail to find any DVB-T2 senders, because it apparently defaults to frontend0, which is DVB-T only. In VDR 2.3.8, I have only been able to view DVB-T from the first frontend. When I did a trick and renamed /dev/dvb/adapter0/frontend1 to frontend0 before starting VDR, VDR no longer complained that the DVB-T2 channels (which I converted from the dvb_channel.conf to channels.conf with dvb-format-convert) not being available, but it did not seem to receive anything from these channels either. Also, after using dvbv5-scan or dvbv5-zap, I sometimes have to invoke w_scan to "reset" the hardware so that VDR can receive DVB-T channels. I would like to receive and record DVB-T and DVB-T2 on this setup. I am willing to try patches or do some programming myself, but I would appreciate some hints to get started. Marko

2 7

French DVB-T Channel IDs vs. EIT Channel IDs
by Patrick Boettcher 25 Jan '20

25 Jan '20

Hi list, since some time (1-2 years) I noticed that the DVB-T channels do not show EPG anymore. I'm not sure what is the root-cause: either it was the migration of French DVB-T to HD (in 2016) or an update of VDR. Anyway, this morning I took the time to figure out what is wrong and here is what I found. In short, the channel-ID generated from the one received in the EIT does not correspond to a known channel-ID from the channel list, and VDR drops the whole section: In cEIT::cEIT (from eit.c) we see tChannelID channelID(Source, getOriginalNetworkId(), getTransportStreamId(), getServiceId()); cChannel *Channel = Channels->GetByChannelID(channelID, true); and channel is NULL in my case. I added some debug prints to GetByChannelID() in the search loop: printf("sid: %d == %d, %s, %s %d\n", Channel->Sid(), sid, (const char *)ChannelID.ToString(), (const char *)Channel->GetChannelID().ToString(), Channel->GetChannelID() == ChannelID); And here is an example of what I get: sid: 517 == 517, T-8442-2-517, T-0-506-517 0 The internal channel ID of vdr reads T-0-506-517. 517 is the SID, 506 is the radio-channel frequency in MHz. This is the right internal channel for this EIT-section. The EIT-channel-ID is telling me that 8442 is the original network ID and 2 might be the radio-channel ID. I tweaked the operator==() of ChannelID to make it work, but not in a contributable manner. How should this be fixed correctly? Is this a regression introduced somewhere? Can it be solved by configuration? Thanks for any help. best regards, -- Patrick.

4 22

[ANNOUNCE] VDR version 2.4.1 released
by Klaus Schmidinger 17 Jun '19

17 Jun '19

VDR version 2.4.1 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.4.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.4.0-2.4.1.diff MD5 checksums: b2897fe6b6e6711d512a69642b1b8ec1 vdr-2.4.1.tar.bz2 cf5f328165e1a48e28e68b6709312e63 vdr-2.4.0-2.4.1.diff This version fixes a few bugs that came up after the release of version 2.4.0. The changes since version 2.4.0: - Fixed handling the tfRecording flag in the SVDRP commands MODT and UPDT (reported by Johann Friedrichs). - Fixed a possible invalid locking sequence in case a remote timer handling error message is displayed on the OSD and the skin tries to lock the Recordings or DeletedRecordings list in its Flush() function (for instance by calling cVideoDiskUsage::HasChanged()). To do this, the call to Skins.Message() in menu.c's HandleRemoteModifications() has been changed to Skins.QueueMessage(), and cSkins::ProcessQueuedMessages() is now called unconditionally in the main loop, and checks whether the current cSkinDisplay object (if any) implements SetMessage(). - Fixed locking the Channels list in cDisplayChannel, where the lock was still held when Flush() was called (reported by Matthias Senzel and Uwe Scheffler). - Fixed shutdown after user inactivity in case a plugin is keeping the OSD open (reported by Ulrich Eckhardt). - Fixed switching through encrypted channels with the Up/Down keys (thanks to Helmut Binder). - Now deactivating MTD support if a non MCD capable CAM is inserted after removing a previously used CAM that is MCD capable (thanks to Helmut Binder). - Added support for DVB devices with more than one frontend that all use the same dvr and demux. Note that in order for this to work, you must not set symbolic links like "demux1 -> demux0" and "dvr1 -> dvr0", as is mentioned in some user manuals of multi frontend DVB cards. - Reverted the change "The EIT filter no longer parses data from "other TS"...". It led to missing EPG data on channels from Canal Digital Norway (reported by Stian B. Barmen). - Fixed accessing the actual frontend on multi frontend devices (thanks to Helmut Binder). - Fixed opening the UDP port in peerdemo (thanks to Robert Hannebauer). - Fixed handling PATs that contain no PMTs. - Fixed processing the last entry in the scan list of the EIT scanner (thanks to Helmut Binder). - Fixed processing transponder data in the NIT (thanks to Helmut Binder). - Fixed triggering the SDT filter when parsing the NIT (thanks to Helmut Binder). - Added support for EAC3 audio from other sources (thanks to Jürgen Schneider). - No longer logging tuning timeouts for transponders that are announced in the NIT but are not currently broadcasting. - Fixed processing SI::T2DeliverySystemDescriptor when typecasting it over an SI::ExtensionDescriptor (reported by Helmut Binder). - Fixed sorting recordings alphabetically. - Fixed dropping capabilities in case cap_sys_time is not available. - Fixed updating the cursor position when switching channels with the Channel+/- keys while the Channels menu is open. - Fixed handling shared CA pids (thanks to Onur Sentürk). - Now touching the .update file in the video directory after removing deleted recordings, so that other VDRs that use the same video directory will update their list of (deleted) recordings and thus won't display too much empty disk space. - Fixed the install target in case of multiple jobs (thanks to Chris Mayo). - Fixed mapping SIDs in MTD (thanks to Helmut Binder). - Fixed updating the checksum in the CA table after mapping EMM PIDs for MTD (thanks to Helmut Binder). - Fixed a compiler warning in ExchangeChars() (thanks to Helmut Binder). - Fixed a compiler warning and a possible buffer overflow in cCiMMI::SendAnswer(). - Fixed a possible invalid lock sequence if the main menu is open and the user switches to a channel that is currently not available, using the Channel+/- keys. - Fixed handling remote timers in case the response to LSTT is '550 No timers defined'. - Fixed a compiler warning in cIndexFile::ConvertToPes() and added __attribute__((packed)) to tIndexPes and tIndexTs (suggested by Helmut Binder). - Fixed handling repeat function for keyboards. - Added a workaround for broadcasters who set an event to status "not running" where this is inappropriate; implicitly setting events to "not running" is now also logged. - Fixed asserting free disk space in case there is no local timer currently recording. - The default maximum size of a cPixmap has been raised to the maximum possible value. - Increased PLAYERBUFSIZE to (MAXFRAMESIZE * 5) to avoid stuttering replay under heavy system load, and to better document that this buffer size is related to the maximum frame size. - Fixed inconsistent behavior in case only certain devices are used (selected by the '-D' option). - Fixed a wrong variable name in cFileName::cFileName(). - If cSkins::Message() is called from a background thread and Type is not mtStatus, the call is now automatically forwarded to QueueMessage(). - Fixed handling the S2SatelliteDeliverySystemDescriptor for transponders broadcasting in "backwards compatibility mode" according to ETSI EN 300 468 (thanks to Onur Sentürk). Have fun! Klaus

1 0

VDR reports wrong disk usage
by Damien Bally 15 Jun '19

15 Jun '19

Hi My vdr recordings are stored on an openmediavault server. The vdr box (rpi 2) is given access to them by nfs. # df -ah /mnt/mmcblk0p3/tv Filesystem Size Used Available Use% Mounted on 192.168.0.40:/export/vdrrecords 3.6T 1.2T 2.5T 32% /mnt/mmcblk0p3/tv VDR nevertheless wrongly reports : Total: 1:02h (1.6GB) | Free: 1:01h (1.5GB) The problem appeared when I switched from MLD 5.1 to MLD 5.4 (VDR ver. 2.4.0) It seems like VDR kept disk usage of the SD card before mounting the nfs share in /etc/fstab. How can I fix this ? Thank you for helping Damien

1 0

Tuning on multi-standard PCI card not testing all frontends
by Nick Burrett 09 Jun '19

09 Jun '19

I have a TBS 6522 tuner card, which has 4 ports, presented as two DVB devices. The DVB-C/DVB-T ports share the same muxer as the DVB-S/S2. VDR correctly detects this: Jun 09 13:29:13 tv.house vdr[16535]: [16535] DVB API version is 0x050B (VDR was built with 0x050B) Jun 09 13:29:13 tv.house vdr[16535]: [16535] frontend 0/0 provides DVB-T,DVB-T2,DVB-C,ISDBT,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("TurboSight TBS 6522 DVB-S/S2/DVB-T/T2/C ") Jun 09 13:29:13 tv.house vdr[16535]: [16535] frontend 0/1 provides DVB-S,DVB-S2,DSS with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Silicon Labs Si2183") Jun 09 13:29:13 tv.house vdr[16535]: [16535] frontend 1/0 provides DVB-T,DVB-T2,DVB-C,ISDBT,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("TurboSight TBS 6522 DVB-S/S2/DVB-T/T2/C ") Jun 09 13:29:14 tv.house vdr[16535]: [16535] frontend 1/1 provides DVB-S,DVB-S2,DSS with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Silicon Labs Si2183") Jun 09 13:29:14 tv.house vdr[16535]: [16535] found 2 DVB devices Currently I have DVB-T connected to /dev/dvb/adapter0/frontend0 and a DVB-S connected to /dev/dvb/adapter1/frontend1. The streams from DVB-T work fine but the DVB-S streams do not work at all. The problem appears to be that VDR never attempts to test frontend 1/1 for a signal and instead continually retries frontend 0/1: Jun 09 14:14:30 tv.house vdr[16891]: [16897] frontend 0/1 timed out while tuning to channel 26 (BBC Two HD), tp 210847 Jun 09 14:15:33 tv.house vdr[16891]: [16897] frontend 0/1 timed out while tuning to channel 26 (BBC Two HD), tp 210847 Jun 09 14:16:36 tv.house vdr[16891]: [16897] frontend 0/1 timed out while tuning to channel 26 (BBC Two HD), tp 210847 Jun 09 14:17:40 tv.house vdr[16891]: [16897] frontend 0/1 timed out while tuning to channel 26 (BBC Two HD), tp 210847 Jun 09 14:18:44 tv.house vdr[16891]: [16897] frontend 0/1 timed out while tuning to channel 26 (BBC Two HD), tp 210847 It would be useful if it were possible to change the --device parameter to be more explicit about which DVB devices should be enabled e.g. --device=A,F;A,F i.e. --device=0,0;1,1 from my configuration so that VDR wouldn't unnecessarily keep trying to get a signal from frontend 0/1. Regards, Nick

1 1

Re: [vdr] Index of /Developer/Patches/vdr-2.4
by Klaus Schmidinger 03 Jun '19

03 Jun '19

On 03.06.19 21:18, Karim AFIFI wrote: > ... > Do you plan to provide soon a vdr-2.4.1 release with all of them ? Yes. There is one problem with the channel display on the Raspberry Pi that still needs to be solved, and after that I'm planning to release version 2.4.1. Klaus

2 1

Re: [vdr] Questions about good hardware to view VDR 4K
by Karl-Heinz Volk 03 Jun '19

03 Jun '19

I just purchased an Amazon FireTV 4k stick and this is amazing. It is working until 2160p60 consuming 1..2 Watt using an USB power supply. Why is there no VDR for Android using network DVB sources? Kind Regards Karl-Heinz Am Mi., 8. Mai 2019 um 19:01 Uhr schrieb Karim AFIFI < karim.afifi(a)laposte.net>: > Hi, > > I am looking for an ATX motherboard with PCI and PCIE slots, for using > with new VDR 4K (PCI S2-3200+CI and PCIE Hauppauge quad), and ASTERISK (PCI > Digium FXO/FXS card). > > At the beginning, I was thinking about an Intel 1151 socket (for best > vaapi support), like this one (*): > > https://www.asus.com/Motherboards/TUF-H310-PLUS-GAMING/HelpDesk_Manual/ > > Unfortunately, I noticed HDMI is v1.4, with 4k@24Hz only ! > > I am afraid that I need to add a PCI-E video card to achieve 4k@60Hz. > > Is it correct ? If so, I have two questions : > 1) could you advice about fanless + VAAPI compatible product ? > 2) any feedback about best plateform/chipset : AMD vs Intel ? > > Thanks a lot. > Karim > > > (*) using with low TDP quad core CPU, for example i3-8100T. > > > _______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- Karl-Heinz Volk Pastorenweg 78 B 28237 Bremen

5 4

Re: [vdr] VDR 2.20 skincurses build error GCC7
by Richard F 03 Jun '19

03 Jun '19

Thanks Klaus - that got it. Can I ask a more general question to the list...? I'm still on 2.20 and noted quite a few changes in 2.4. I'd like to update, but I run with essential (for me) patches such as the HD-EPG, VPS, and 1 or 2 others... maybe obsolete now. I see a number of plugins now minimally maintained, if at all, and I think some changes to the API recently. What chance of rebuilding all of this for 2.4? E.g. smarttvweb plugin also doesn't build under GCC7 (bug logged), but no activity for a couple of years. My plugins: streamdev-server epgsearch epgtableid0 vnsiserver vdrmanager dummydevice smarttvweb + vdradmin-AM, VDR-zapper, xmltv2vdr Thanks for any feedback On 3/06/2019 13:00, vdr-request(a)linuxtv.org wrote: > Subject: > Re: [vdr] VDR 2.20 skincurses build error GCC7 > From: > Klaus Schmidinger <Klaus.Schmidinger(a)tvdr.de> > Date: > 3/06/2019, 09:36 > > To: > vdr(a)linuxtv.org > > > On 03.06.19 10:30, Richard F wrote: >> Hi, >> >> I'm not sure how relevant the skincurses plugin is, but I can no longer >> build it under GCC7 (Opensuse 15.1) > > Please try this patch: > > > http://ftp.tvdr.de/Developer/Patches/vdr-2.4/vdr-2.4.0-15-fix-skincurses.di… > > > Klaus

2 1

VDR 2.20 skincurses build error GCC7
by Richard F 03 Jun '19

03 Jun '19

Hi, I'm not sure how relevant the skincurses plugin is, but I can no longer build it under GCC7 (Opensuse 15.1) skincurses.c:133:52: error: invalid use of incomplete type ?WINDOW {aka struct _win_st}? copywin(savedRegion, window, 0, 0, savedRegion->_begy, savedRegion->_begx, savedRegion->_maxy - savedRegion->_begy, savedRegion->_maxx - savedRegion->_begx, false); I think I have the required library sources, but always possible not. Any clues? Thanks

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr June 2019