vdr November 2017

vdr@linuxtv.org

9 participants
5 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

VDR ISDB-T support
by Christian Rodriguez 14 Sep '18

14 Sep '18

Hello everyone! I'm from Argentina, and up to last month I've been using VDR 1.7.262 with an ISDB-T USB adapter. It works really good, but the last week I've been trying to upgrade to VDR 2.2 and I've found a problem with ISDB-T cards: they are not supported. As I'm really interested in using VDR, I was digging inside the code and found a partial solution for this problem: as ISDBT is the same as DVBT, I've changed the way delivery system is queried. My changes are applied in a cloned repo at github: https://github.com/chrodriguez/vdr/commit/dadbca57c2dc55c1c53b4fa8f68b56728… That's the only change I've made. Now I can enjoy my fresh upgraded VDR installation!! I think a better refactor should be made, but for now it's working perfectly deployed as a docker container: https://registry.hub.docker.com/u/chrodriguez/vdr Thanks for this wonderfull project! -- Lic. Christian A. Rodriguez @car_unlp

4 7

VDR locking up
by VDR User 29 Dec '17

29 Dec '17

Occasionally my signal drops out (haven't looked into it yet), and it causes VDR to completely freeze and become defunct/zombie. That locks up the drivers and the only way to resolve it is by rebooting. No core file gets created. Does anyone know how to prevent the lock-up in the first place? Could it be some kind of leak from the looping (see log clip below)? Here's a clip of the log when it happens. You can see how the log gets filled with the same repeating lines until it crashes. 2016.Oct.28|12:08:55 video: slow down video, duping frame 2016.Oct.28|12:08:55 video: decoder buffer empty, duping frame (5656/167423) 7 v-buf 2016.Oct.28|12:09:29 video: slow down video, duping frame 2016.Oct.28|12:16:09 [1297] [softhddev]Clear: 2016.Oct.28|12:16:09 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:09 audio/alsa: using device 'default' 2016.Oct.28|12:16:09 audio/alsa: start delay 336ms 2016.Oct.28|12:16:09 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear: 2016.Oct.28|12:16:13 audio/alsa: using device 'default' 2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear: 2016.Oct.28|12:16:13 audio/alsa: using device 'default' 2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear: 2016.Oct.28|12:16:13 audio/alsa: using device 'default' 2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear:

4 12

Watching VDR recordings and live TV on mobile
by Teemu Suikki 19 Nov '17

19 Nov '17

Hi, I have been investigating methods to view VDR recordings and live TV when traveling, with an Android phone and possible Chromecast. Here's some pros can cons of the different methods I have tried: VDR Manager plugin + android app: https://projects.vdr-developer.org/projects/vdr-manager/wiki + Very clean app, great recordings and channel listings, easy to use. + Can also edit timers, use as remote control for VDR + DVB Subtitles work in both live and recordings! - Recordings can't be seeked, at least not with Android VLC! Very annoying.. - No transcoding for recordings, so must have a quick connection - Also Live-TV is transcoding is only with Streamdev's externremux, which is not very good. Then there is Plex Media Server with VDR.bundle and plex-vdr-live-tv.bundle: https://hub.docker.com/r/jondalar/plex/ + Nice app, although a bit complex for just VDR use. + Plex has very good transcoding with automatic rate control, based on your downlink speed + DVB subtitles work in recordings. + Recordings are seekable. + Plex is great for other media too, mp3 and movies etc - No DVB subtitles in live tv! - No other VDR control (timers) - No EPG, expect for current programs - Recordings are difficult to use, hard to find episodes of TV shows in correct order.. Does anyone have suggestions or ideas where to go from here? :) Plex stuff looks like it's not updated for years, but it also is something I could perhaps improve myself. VDR Manager's biggest problem is the lack of transcoding, but that would be very difficult to add. -- Teemu Suikki http://www.z-power.fi/

5 5

Feature request: sort recording like extrecmenu plugin does
by carel＠nekanali.nl 10 Nov '17

10 Nov '17

Hello Klaus Would it be possible to add a new sort mode for the recordings in the new stable vdr release? On top directories sorted on date from date high to -low Below that the recordings from date high to low. Later option is now only available on low to high date sort Thanks a lot Carel

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2017