vdr

vdr@linuxtv.org

6732 discussions

option parsing for --log still broken
by Harald Milz 18 Nov '20

18 Nov '20

Hi Klaus and all, it appears that option parsing for the --log option is still broken, as described in this thread: https://www.vdr-portal.de/forum/index.php?thread/108924-gel%C3%B6st-logging… Short version: vdr stops parsing the remainder of the command line at the point of --log=2.6. Long version: The problem is in the getopt code in vdr.c: case 'l': { char *p = strchr(optarg, '.'); if (p) *p = 0; if (isnumber(optarg)) { int l = atoi(optarg); if (0 <= l && l <= 3) { SysLogLevel = l; if (!p) break; if (isnumber(p + 1)) { int l = atoi(p + 1); if (0 <= l && l <= 7) { int targets[] = { LOG_LOCAL0, LOG_LOCAL1, LOG_LOCAL2, LOG_LOCAL3, LOG_LOCAL4, LOG_LOCAL5, LOG_LOCAL6, LOG_LOCAL7 }; SysLogTarget = targets[l]; break; } } } } if (p) *p = '.'; fprintf(stderr, "vdr: invalid log level: %s\n", optarg); return 2; } Initially, the point is replaced by a NULL byte in order to be able to atoi() both numbers (if (p) *p = 0;). This replacing takes place _in place_. In theory, the replace should be reverted at the end of the code snippet (if (p) *p = '.';) BUT if one of the branches involving a break is executed, the revert is never invoked, and the original command line remains broken so that the remaining command line options are not getting evaluated. Consequently, what used to be vdr -w 60 -g -u vdr -l 2.6 -P plugin1 -P plugin2 becomes vdr -w 60 -g -u vdr -l 2 6 -P plugin1 -P plugin2 and the modules will not get loaded. The thread mentioned above speaks of upstart & co but I have the same issue in a docker container with explicit program start in a shell script whithout any upstart or anything. I now helped myself putting the -l at the end of the command line but I still cannot send the vdr log to a different facility because the dangling 6 is not getting evaluated. My suggestion would be to not evaluate the optarg string directly but create a copy of optarg first, and work with the copy. This way, the original command line is unchanged. Sample patch attached, untested but it should do the trick. -- You are as I am with You.

2 2

Re: [vdr] Many "Tuning timeout" messages and signal disruptions
by Richard F 17 Nov '20

17 Nov '20

I'd either use bare metal or maybe a container (LXC, not sure sure about docker) as that's as near as bare metal with few encumbrances. Why ? I've always used bare metal, and it seems VDR is working quite close to the hardware, adding layers adds complexity. But the other thing is that that sever looks quite ancient now and a replacement (somewhat newer, if not new) shouldn't cost much. I had a similar issue with a CCTV card unrecognised by the kernel and gave up fighting the FOXCONN mobo/BIOS, after some discussion and help on the kernel developers forum who tried but ultimately couldn't help in the end, and bought an-off-the shelf HP machine for only around 100 euro / used. There were other benefits, like super-efficient PSU giving power eduction which in the 4 or 5 years since may have paid for it ! The ugly bit is ideally you need a kind soul to let you test your card in whatever machine first, to be sure it works. On 13/11/2020 12:00 pm, vdr-request(a)linuxtv.org wrote: > potential solutions: > - run VDR in a docker container instead of in a VM and pass /dev/dvb to the > container > - replace the KVM host, thus get rid of the RMRR issue and continue to use PCI > passthrough > - run the VDR on bare metal > - others? > > What would you do if you were in my place, and why?

1 0

Many "Tuning timeout" messages and signal disruptions with minisatip and the satip plugin
by Harald Milz 12 Nov '20

12 Nov '20

Hi guys, I migrated my VDR and my KVM host to Ubuntu 20.04-latest lately. The KVM host has the sat card (Digital Devices Cine S2 V6.5 DVB adapter), the driver stack (0.9.33-integrated), plus minisatip-latest from git, and the vdr VM runs the normal Ubuntu stack with vdr-2.4.1 and satip-2.4.0 (plus xineliboutput and vnsiserver). I use two satellites, Astra 19.2E and Hotbird S13E, with 2 receivers each. The stack basically works, but after some time the messages "SATIP-ERROR: Tuning timeout" get more and more and the usual artifacts occur. The WAF factor is not that high as you can tell. Since everything else works nicely, I suspect a problem somewhere between the ddbridge driver, minisatip and the satip plugin. Question: is that the expected behaviour for such a setup? In the old days I used PCI passthrough but this is very inconvenient because the server (HP DL380G6) has a RMRR problem with the sat card, and I had to use custom built kernels all the time... potential solutions: - run VDR in a docker container instead of in a VM and pass /dev/dvb to the container - replace the KVM host, thus get rid of the RMRR issue and continue to use PCI passthrough - run the VDR on bare metal - others? What would you do if you were in my place, and why? TIA! -- Q: Why should you always serve a Southern Carolina football man soup in a plate? A: 'Cause if you give him a bowl, he'll throw it away.

1 0

VDR system on Raspberry pi vs these all in one systems
by Timothy D. Lenz 28 Sep '20

28 Sep '20

My mom (82 years old) is still using a VCR with a tuner box. We are concerned about it wearing out, the tapes no longer being sold, etc.. She just spent $65 on a 9 pack of tapes from Amazon that could have gone to a new setup and she is saying she wants to get another VCR for backup. But they haven't been made in years, so it would already be used. I have a linux computer running VDR with a couple of dual ATSC dual tuner cards. But it needs to be rebuilt/reinstalled and I haven't messed with it in so long, I would have to learn it all over again and I'm not as good at figuring stuff out as I used to be and money is tight. You can get VDR/Linux images ready to go for a Raspberry pi which cost about $35. Add a USB Tuner and a USB drive and you have a digital recorder system. And if I ever get mine rebuilt, they could be linked and share tuners and drive space. But it's complicated and time consuming to setup for me atm. These ready made units would be simpler to get going, but a good one would cost more and be more complicated for her to use. I still have to setup timers for recording with the VCR. I'm looking for recommendations/options/opinions. While the local over the air guide is mostly a mess, sometimes not sending out the prime time data till nearly noon of that day, we'd want to avoid having to sub to any service to keep cost down. Needs to be local recording, be able to use local guide data and when needed setup blind recordings as done on VCRs, and would be nice if you could plug and remove USB drives/sticks for longer term storing recordings. From what I've seen, these ready made systems don't really like media swapping.

2 1

satip plugin and rtp over tcp
by linuxtv at ncs-online 07 Sep '20

07 Sep '20

Hi, according to the description the plugin supports rtp-o-tcp. Unfortunately the payload is not transferred via tcp, but like with unicast via udp. There is no difference between unicast and rtp-over-tcp. Is this a bug or did I do something wrong with the settings? The current settings are as follows: satip.CICAM = 0 0 satip.DisabledFilters =. satip.DisabledSources =. satip.EnableCIExtension = 0 satip.EnableEITScan = 0 satip.EnableFrontendReuse = 1 satip.OperatingMode = 3 satip.TransportMode = 2 Version is 2.4.1 -Carter

1 0

[ANNOUNCE] VDR version 2.4.4 released
by Klaus Schmidinger 02 Aug '20

02 Aug '20

VDR version 2.4.4 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.4.4.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.4.1-2.4.4.diff MD5 checksums: ccf724c157740b2b153ca41ad38f1217 vdr-2.4.4.tar.bz2 12845052da407da62748982c01cc5d52 vdr-2.4.1-2.4.4.diff You can also get the latest version at the official VDR GIT archive with git clone git://git.tvdr.de/vdr.git This version fixes a few bugs that came up after the release of version 2.4.1. The changes since version 2.4.1: - Fixed moving channels between number groups in SVDRP's MOVC command and the Channels menu, in case a channel is moved to a higher number and into a numbered group (reported by Manuel Reimer). - Now retuning if the received transponder's SDT doesn't contain the expected values for NID and TID (thanks to Uwe Scheffler for reporting a problem with failed tuning in SCR systems, and Helmut Binder for helping with the implementation). - Fixed compatibility with current versions of glibc (thanks to Manuel Reimer). - The SVDRP command DELC now also accepts a channel id (suggested by Manuel Reimer). - Fixed dropping capabilities in case cap_sys_time is not available. - Added the language code for Bulgarian (thanks to Helmut Binder). - Fixed handling multi part ExtendedEventDescriptors where only the first part contains information about the character table (based on a patch from Helmut Binder). - When setting the system character table, it is no longer checked against the known entries that are hard coded in libsi/si.c, but rather given to iconv_open() and the result of that call is used to check whether the given name is valid. - Checking whether the system character table is "single byte" is now done by checking the result of a sample call to iconv(). - Setting the override character table now checks and reports whether the given value is valid (suggested by Helmut Binder). - The isSingleByte parameter in the call to getCharacterTable() is deprecated and only present for backwards compatibility. - Fixed a possible crash in case replay is started and stopped in rapid sequence, by adding missing locking to cControl::Control(). The caller of this function must now provide a cMutexLock which stays alive as long as the result of this call is used. The old version of this function is still there for backwards compatibility with plugins, because this problem appears to occur only under very rare circumstances. Authors of plugins that use this function should switch to the new version, because the old one is deprecated and will be removed in a future version. The version numbers (both VDRVERSNUM and APIVERSNUM) have been bumped to 2.4.2, so that plugins can detect the presence of the new cControl::Control(). - Added a missing '-D' to the 'plugins' target of the Makefile (thanks to Johann Friedrichs). - Fixed the size of cChannel::dtypes[] (thanks to Winfried Köhler). The version numbers (both VDRVERSNUM and APIVERSNUM) have been bumped to 2.4.3 to indicate this change. - Added a device hook for detecting whether a device provides EIT data (thanks to Winfried Köhler). - Fixed memory handling in cString::Append() (reported by Stefan Herdler). - Revised 'Fixed a possible deadlock when detaching a receiver from a device' from version 2.3.9, which sometimes caused a black screen when switching channels (thanks to Stefan Verse). - Added failsafe defaults for 'make LCLBLD=1' to the Makefile (thanks to Stefan Herdler). - Added codes for more languages and special audio tracks (thanks to Helmut Binder). - Added cMtdCamSlot::TsPostProcess() (thanks to Helmut Binder). - Added cMtdHandler::StopDecrypting() (thanks to Helmut Binder). - Added support for detecting new channels broadcast in HEVC (thanks to Helmut Binder). - Added support for detecting 'advanced codec digital radio sound service' (thanks to Helmut Binder). - Added handling shared PMT pids and multiple PMT sections (thanks to Helmut Binder). - Changed the country code in the generated ParentalRatingDescriptor from 'DEU' to '902' to make it valid for all countries (thanks to Helmut Binder). - Added optional verbose output to the libsi Makefile (thanks to Tobias Grimm). - Made the call to pkg_config configurable via the PKG_CONFIG macro, which is necessary for cross-building VDR (thanks to Tobias Grimm). Plugin authors may want to modify their Makefiles accordingly by adding the line 'PKG_CONFIG ?= pkg-config' and replacing every occurrence of 'pkg-config' with '$(PKG_CONFIG)', as can be seen in the Makefiles of the plugins that come with the VDR source. - Fixed a typo in svdrp.c (thanks to Tobias Grimm). - Added support for HEVC-video and AC-4-audio (thanks to Christoph Haubrich). - Added a comment about the semantics of cTimeMs::Set(). - Adjusted device selection in GetDeviceForTransponder() to that in GetDevice() (thanks to Helmut Binder). - Now adding CPPFLAGS to CXXFLAGS to allow extra preprocessor flags to be given when doing make (suggested by Tobisa Grimm). - Added CRC check of the CAT in cCaPidReceiver::Receive() (thanks to Helmut Binder). - Fixed the 'else if' branch in cDevice::GetDeviceForTransponder(), which hasn't been active since version 1.7.29 (reported by Helmut Binder). The original purpose of this branch was to use a device that is currently not recording for switching to the transponder of an upcoming VPS timer. However, this caused problems with more than two bonded devices, which was "fixed" in version 1.7.29. Apparently this fix merely rendered the whole code branch inactive. Now this branch is only executed for devices that are not bonded. - Improved deleting plugins in case the plugin uses its own memory management (thanks to Winfried Köhler). Plugins that have been compiled with previous versions of VDR do not need to be recompiled, they will silently be handled as before. - Now setting currentDisplayChannel = NULL before calling cStatus::MsgOsdClear() in ~cDisplayChannel(), to avoid possible problems in case a plugin calls IsOpen() (reported by Thomas Reufer). - Fixed handling inactive shared CA pids (thanks to Helmut Binder). - Implemented handling multi packet CATs with MTD (thanks to Helmut Binder). - Fixed a possible 'invalid lock sequence' when switching to an unavailable channel with the main menu open. - Official release. Have fun! Klaus

1 0

vdr-2.4.1 and xineliboutput: video and audio freeze
by Peter Münster 06 May '20

06 May '20

Hello, On my vdr-box, I cannot watch some channels. For example when switching to France 2, the image stutters and then freezes after some seconds. And the audio output stops too. I have 2 outputs with some messages: 1.) From stdout/stderr (only some samples, because there are a lot of lines): ffmpeg_audio_dec: not enough data to decode metronom: video jump by -23415 pts. metronom: video jump by 72000 pts. video_out_vdpau: b 0 c 128 s 128 h 0 [ITU-R 709 / HDTV] ffmpeg_audio_dec: not enough data to decode video_out: throwing away image with pts 24396186 because it's too old (diff : 124178). ffmpeg_audio_dec: not enough data to decode metronom: video jump by -48960 pts. video_out: throwing away image with pts 24358421 because it's too old (diff : 286741). ffmpeg_audio_dec: not enough data to decode audio_out: flushed out 0 buffers. ffmpeg_audio_dec: resetting parser audio_out: ao_flush (loop running: 1) set_speed 0. video_out: new speed 0. set_speed 1000000. video_out: new speed 1000000. audio_out: new speed 1000000. audio_out: flushed out 0 buffers. audio_out: flushed out 0 buffers. ffmpeg_audio_dec: resetting parser audio_out: ao_flush (loop running: 1) metronom: prebuffer=14400 pts. metronom: video discontinuity #78, type is 3, disc_off 0. metronom: waiting for audio discontinuity #78... ffmpeg_audio_dec: resetting parser metronom: audio discontinuity #78, type is 3, disc_off 0. metronom: vpts adjusted with prebuffer to 24818015. metronom: prebuffer=2000 pts. metronom: prebuffer=14400 pts. video_out_vdpau: b 0 c 128 s 128 h 0 [ITU-R 470 BG / SDTV] metronom: prebuffer=14400 pts. set_speed 0. 2.) From syslog: vdr[2239]: [2252] [vdr-fe] Keypress: XKeySym Next vdr[2239]: [2239] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB vdr[2239]: [2239] switching to channel 39 T-8442-1-257 (France 2) vdr[2239]: [2735] device 1 TS buffer thread ended (pid=2239, tid=2735) vdr[2239]: [2734] buffer stats: 91932 (1%) used vdr[2239]: [2734] device 1 receiver thread ended (pid=2239, tid=2734) vdr[2239]: [2788] device 1 receiver thread started (pid=2239, tid=2788, prio=high) vdr[2239]: [2789] device 1 TS buffer thread started (pid=2239, tid=2789, prio=high) vdr[2239]: [2262] [demux_vdr] PMT changed, resetting demuxer vdr[2239]: [2788] [xine..put] H.264: Found NAL SPS at offset 6/156 vdr[2239]: [2788] [xine..put] H.264 SPS: profile_idc 100 vdr[2239]: [2788] [xine..put] H.264 SPS: pic_width: 120 mbs vdr[2239]: [2788] [xine..put] H.264 SPS: pic_height: 34 mbs vdr[2239]: [2788] [xine..put] H.264 SPS: frame only flag: 0 vdr[2239]: [2788] [xine..put] H.264 SPS: MBAFF vdr[2239]: [2788] [xine..put] H.264 SPS: cropping 0 0 0 2 vdr[2239]: [2788] [xine..put] H.264 SPS: aspect_ratio_idc 1 vdr[2239]: [2788] [xine..put] H.264 SPS: -> aspect ratio 1 / 1 vdr[2239]: [2788] [xine..put] H.264 SPS: -> video size 1920x1080, aspect 1:1 vdr[2239]: [2788] [xine..put] Detected video size 1920x1080 vdr[2239]: [2262] [demux_vdr] audio stream changed: 00000000 -> 03410000 vdr[2239]: [2788] ERROR: 1 TS packet(s) not accepted in Transfer Mode vdr[2239]: [2788] [xine..put] H.264: Found NAL SPS at offset 6/156 vdr[2239]: [2788] [xine..put] H.264 SPS: profile_idc 100 vdr[2239]: [2788] [xine..put] H.264 SPS: pic_width: 120 mbs vdr[2239]: [2788] [xine..put] H.264 SPS: pic_height: 34 mbs vdr[2239]: [2788] [xine..put] H.264 SPS: frame only flag: 0 vdr[2239]: [2788] [xine..put] H.264 SPS: MBAFF vdr[2239]: [2788] [xine..put] H.264 SPS: cropping 0 0 0 2 vdr[2239]: [2788] [xine..put] H.264 SPS: aspect_ratio_idc 1 vdr[2239]: [2788] [xine..put] H.264 SPS: -> aspect ratio 1 / 1 vdr[2239]: [2788] [xine..put] H.264 SPS: -> video size 1920x1080, aspect 1:1 vdr[2239]: [2788] [xine..put] Detected video size 1920x1080 What could I do please, do watch such channels? Thanks in advance for any hints. Kind regards, -- Peter

1 0

VDR findet S13E nicht mehr nach Upgrade
by Harald Milz 01 May '20

01 May '20

Servus, ich brauche ausnahmsweise mal Hilfe ;-) Nach längerem habe ich mich endlich aufgerafft, meinen VDR von Ubuntu 14.04 / Kernel 4.4.0 / vdr-2.2.0 / dddvb-0.9.32 hochzuziehen auf Ubuntu 18.04 / Kernel 4.15.0 / yavdr-2.4.0 / dddvb-0.9.38 (latest aus git). An den Configs habe ich nichts geändert. Die Karte ist eine DDBridge V 6.5 mit 4 Tunern. 1 und 2 liegen auf Astra S19.2E, die beiden anderen auf Hotbird S13E. Die LNBs sind zwei Quad von Kathrein, von denen jeweils nur die ersten beiden Ausgänge belegt sind. Die disecq.conf ist die Standardeinstellung dafür wie aus dem Wiki, was immer prima funktioniert hat. Aber jetzt nicht mehr: Kanäle auf Astra werden ohne weiteres gefunden, aber der VDR versucht nun S13E-Kanäle mit Tuner 1 oder 2 zu finden, was natürlich scheitert: Apr 30 17:41:47 vdr vdr: [16550] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD) Apr 30 17:41:47 vdr vdr: [16851] device 1 receiver thread started (pid=16550, tid=16851, prio=high) Apr 30 17:41:47 vdr vdr: [16852] device 1 TS buffer thread started (pid=16550, tid=16852, prio=high) ... Apr 30 17:42:10 vdr vdr: [16550] switching to channel 61 S13.0E-318-12400-8511 (Rai 1) Apr 30 17:42:10 vdr vdr: [16852] device 1 TS buffer thread ended (pid=16550, tid=16852) ... Apr 30 17:42:10 vdr vdr: [16851] device 1 receiver thread ended (pid=16550, tid=16851) Apr 30 17:42:10 vdr vdr: [16854] device 1 receiver thread started (pid=16550, tid=16854, prio=high) Apr 30 17:42:10 vdr vdr: [16855] device 1 TS buffer thread started (pid=16550, tid=16855, prio=high) Apr 30 17:42:19 vdr vdr: [16554] frontend 0/0 timed out while tuning to channel 61 (Rai 1), tp 210992 Ich hätte erwartet, dass er dafür frontend 2/0 oder 3/0 verwendet. Auf denen wirft er aber ständig Timeouts zu Channels von S19.2E. In /dev/dvb stehen alle 4 Adapter, und der VDR erkennt sie auch (found 4 DVB devices). Möglicherweise habe ich verpasst, weil ich sehr lange nicht danach geschaut habe, dass sich an den diesbezüglichen Configs von vdr-2.2.0 nach -2.4.0 was geändert hat. Wo muss ich hinschauen? Danke! -- You are only young once, but you can stay immature indefinitely.

2 2

20 Years of VDR / Announcing "GeoTagger"
by Klaus Schmidinger 29 Apr '20

29 Apr '20

Twenty years ago today, I released the first version of the VDR source. A pretty long time, in which much has happened. Back then a VDR was something special, while today it's just an ordinary device. But still it feels good to be able to tweak things yourself. Lately it's been rather quiet from my side, regarding the VDR development. For one this was because it just works fine in every day life. But I was also busy working on a totally different project. I wanted to add/adjust the GPS coordinates in the many photos that piled up over the years (partly scanned from negatives). Unfortunately there was no application available under Linux that really fit my needs (maybe I just missed that one great program ;-). So I decided to do some development of my own, and today, for the 20th "birthday" of VDR, I'd like to present the result: http://www.tvdr.de/geotagger This is the very first version to go "out in the wild", so chances are there will still be some quirks. So far I have tested it on Linux (openSUSE Leap 15.0) and Mac OS 10.13. I can't test on Windows, because I don't have such a system. Maybe it can be of some use to some of you out there, too. Please send problem reports directly to me, so we don't clog this mailing list. Klaus

4 4

Filtering encrypted channels
by Daniel 08 Apr '20

08 Apr '20

Hi List, i'm using vdr 2.2.0-r5 + vnsi + kodi and I wonder if there is a way to automatically filter encrypted tv channels from channels.conf. My Problem is, that new channels are constantly added but pay TV channels can't be encrypted. So I have to remove them manually once a week or so. Disabling auto-adding new channels would require me to manually scan once in a while. Disabling it is the best "solution" I came up with until now. If there would be a way to periodically filter them (e.g. at night), I would be very happy. Regards, Daniel

5 15

← Newer
1
2
3
4
5
6
7
8
9
...
674
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr