Re: [vdr] vdr-satip, Digibit R1 and 2 satellites

[Torsten Duwe]

On Thu, 21 Sep 2023 08:28:51 +0200
Torsten Duwe  wrote:

> On Wed, 20 Sep 2023 10:09:29 +0200
> Harald Milz  wrote:
> 
> > In fact I tried to boot satip-axe from a USB stick but for unknown
> > reasons the box stuck to the original FW. :-( 
> 
> You must not partition the medium, but use it in "USB floppy disk mode".
> Put a fat32 on it, with idl4k.scr in the root dir, that should be
> enough to intercept the boot flow.

Oh, and you have to use the *upper* USB-A receptacle, it seems.

> HTH,
>   Torsten

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-satip, Digibit R1 and 2 satellites

[Torsten Duwe]

On Wed, 20 Sep 2023 10:09:29 +0200
Harald Milz  wrote:

> In fact I tried to boot satip-axe from a USB stick but for unknown
> reasons the box stuck to the original FW. :-( 

You must not partition the medium, but use it in "USB floppy disk mode".
Put a fat32 on it, with idl4k.scr in the root dir, that should be
enough to intercept the boot flow.

HTH,
Torsten


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-satip, Digibit R1 and 2 satellites

[Harald Milz]

Hi Torsten, 

long time no hear! Good you're still around! 

On Tue, Sep 19, 2023 at 10:43:01AM +0200, Torsten Duwe wrote:
> There is an alternative firmware for this box

In fact I tried to boot satip-axe from a USB stick but for unknown reasons the
box stuck to the original FW. :-( 

After digging a bit more, it seems that the signal on the two cables coming
from the Hotbird LNB is dead. Also, my other DVB-S2 card refuses to tune in on
these cables. :-( 

No idea why. But this would definitely explain these messages. 

> > Sep 17 19:22:34 seneca vdr: [5170] SATIP-ERROR: Tuning timeout - retuning 
> > [device 2]
> > Sep 17 19:22:34 seneca vdr: [5173] SATIP-ERROR: Tuning timeout - retuning 
> > [device 3]

Ciao,
Harald



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-satip, Digibit R1 and 2 satellites

[Torsten Duwe]

Hi Harald!

On Sun, 17 Sep 2023 19:49:39 +0200
Harald Milz  wrote:

> Hi all,
> 
> I recently got a stone-aged Digibit R1 to replace an even older PCI-E card. 
[...]
There is an alternative firmware for this box

https://github.com/perexg/satip-axe/blob/master/dist/README
https://github.com/Jalle19/satip-axe/

> Sep 17 19:22:34 seneca vdr: [5170] SATIP-ERROR: Tuning timeout - retuning 
> [device 2]
> Sep 17 19:22:34 seneca vdr: [5173] SATIP-ERROR: Tuning timeout - retuning 
> [device 3]
> 
> over and over. What am I missing?

I can't tell off hand, but maybe more debugging taps can help to narrow it down?

Torsten
 

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR keeps a tuner busy when a recording is paused

[Richard F]

On 28/11/2022 18:17, Marko Mäkelä wrote:

Mon, Nov 28, 2022 at 12:27:08PM +, Richard F wrote:
FYI I'm using the powersaving patch on a system with an Astrometa USB 
stick + an old Winfast PCI receiver, and I see 2-3W reduction when 
the Astrometa frontend is shut down:


I only tested with a single receiver. Your patch may very well switch 
off any additional receivers, but it seems to me that one front-end 
would always remain enabled.


Yes - true - I only see frontend 1/0 powering down

Richard


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR keeps a tuner busy when a recording is paused

[Marko Mäkelä]

Mon, Nov 28, 2022 at 12:27:08PM +, Richard F wrote:
FYI I'm using the powersaving patch on a system with an Astrometa USB 
stick + an old Winfast PCI receiver, and I see 2-3W reduction when the 
Astrometa frontend is shut down:


I only tested with a single receiver. Your patch may very well switch 
off any additional receivers, but it seems to me that one front-end 
would always remain enabled.


Today, I measured the power consumption again, with the Pi TV HAT 
attached, but without an aerial cable. The setup is a bit flimsy; like 
last year, the Raspberry Pi is displaying an undervoltage warning icon 
on the top right corner. I do not dare to over-volt the power supply.


For comparison, I am quoting my figures from last year, without the Pi 
TV HAT, and with/without the Astrometa stick:



I measured the following current draw at 5 volts, in ascending order:

81 mA: Raspberry Pi 2B shut down


127 mA: Raspberry Pi 2B + TV HAT shut down


200 mA: Raspberry Pi 2B powered up, no Ethernet plugged in
240 mA: Ethernet cable plugged in (HDMI cable makes no difference)


256 mA: Ethernet cable plugged in; Pi TV HAT attached
267 mA: Ethernet + HDMI plugged in; Pi TV HAT attached


320 mA: Ethernet + USB DVB stick plugged in
440 mA: compiling VDR with "make -j4" (all CPU cores busy)


480 mA: compiling (peak; sometimes as low as 300 mA)


550 mA: VDR playing back a recording
530 mA: recording paused in VDR
510 mA: EPG scan running
600 mA: VDR displaying live DVB-T2


440 mA: VDR started up, blank screen (no aerial plugged in)
510 mA: VDR playing back a recording (peak value)
450 mA: recording paused in VDR

This time, I did not plug in an aerial cable at all. I would guess that 
displaying live TV would consume at most 550 mA.


As you can see from the above, the idle consumption is about 260 mA.  
When VDR is seemingly idle, I am seeing additional consumption of around 
200 mA.


Notably, after I killed the vdr process, the power consumption would 
hover around 330 mA. It could be that my version of rpihddevice is not 
properly shutting down all processes on the Videocore IV GPU. After I 
restarted the VDR process, I got a similar power consumption as above.


While it does not like we can blame the active tuner for all of the 
additional consumption of 200 mA, I think that we can attribute at least 
100 mA to it. The difference between 260 mA and 450 mA is +70%, not 
insignificant.


I am glad to see that the Pi TV HAT is consuming less power than the 
Astrometa stick. It is logical, because the TV HAT does not have to run 
an additional 8051 microcontroller and a step-down SMPS to produce 3.3V 
from the 5V USB supply, and presumably at least one separately packaged 
memory chip.


But I'm still running V2.20 and have a workaround for the 2 frontends 
on the Astometa - both for reasons mentioned before on this list.


Yes, I remember the frontend-swapping issue on the Astrometa. It may 
have been fixed in 2.6. I didn't try the Astrometa stick on my Pi after 
reinstalling Raspberry OS Legacy from the scratch.


Marko

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR keeps a tuner busy when a recording is paused

[Richard F]

I conducted this test without applying the patch
https://github.com/glenvt18/vdr/commit/b368f67d00d0b466ae36028efb9336e81f77dba8 



As far as I can tell, even with that patch the EPG parser could keep 
running, because the patch does not set the variable InhibitEpgScan.  
That would explain why the patch did not help reduce VDR power 
consumption with the Astrometa USB stick.



Thanks for the info on CPU use etc.

FYI I'm using the powersaving patch on a system with an Astrometa USB 
stick + an old Winfast PCI receiver, and I see 2-3W reduction when the 
Astrometa frontend is shut down:


Nov 27 20:13:09 ha-server vdr[7196]: [7196] frontend 1/0 provides DVB-T,DVB-T2,DVB-C with 
QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Sony CXD2837ER DVB-T/T2/C demodulator")

Nov 27 20:49:08 ha-server vdr[12959]: [12959] dvb tuner: power-down - closing 
frontend 1/0

But I'm still running V2.20 and have a workaround for the 2 frontends on 
the Astometa - both for reasons mentioned before on this list.


HTH/Richard


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Tobi]

Many thanks to Klaus for version 2.6.0!

For the state of the Debian packages see:

https://qa.debian.org/developer.php?email=pkg-vdr-dvb-devel%40lists.alioth.debian.org

Besides this I have in my private repository:

deb https://packages.e-tobi.net/vdr-experimental bullseye base
vdr-multipatch addons
deb-src https://packages.e-tobi.net/vdr-experimental bullseye base
vdr-multipatch addons


vdr-addon-acpiwakeup0.0.13
vdr-dev 2.6.0-1~etobi1
vdr-plugin-dummydevice  2.0.0-6
vdr-plugin-dvbhddevice  2.2.0-15
vdr-plugin-dvbsddevice  2.2.0-15
vdr-plugin-dvd  0.3.6~b03+git20211216-2
vdr-plugin-epg2vdr  1.2.5-1
vdr-plugin-epgsearch2.4.1-2
vdr-plugin-epgsync  1.0.1-8
vdr-plugin-examples 2.6.0-1~etobi1
vdr-plugin-femon2.4.0-5
vdr-plugin-fritzbox 1.5.4-2
vdr-plugin-graphlcd 1.0.6-2
vdr-plugin-imonlcd  1.0.3-1
vdr-plugin-iptv 2.4.0-3
vdr-plugin-live 3.1.3-2
vdr-plugin-menuorg  0.5.2-3
vdr-plugin-mp3  0.10.4-2
vdr-plugin-mplayer  0.10.4-2
vdr-plugin-noepg0.0.5-3
vdr-plugin-osdserver0.1.3-22
vdr-plugin-osdteletext  2.3.1-1
vdr-plugin-pvrinput 2015-11-07-4
vdr-plugin-remote   0.7.0-6
vdr-plugin-satip2.4.1-2
vdr-plugin-skindesigner-dbg 1.2.17-1
vdr-plugin-skindesigner 1.2.17-1
vdr-plugin-skinelchi0.3.0-4
vdr-plugin-skinenigmang 0.1.2+git20190720-4
vdr-plugin-skinflatplus 0.6.1-3
vdr-plugin-skinsoppalusikka 2.4.0-2
vdr-plugin-softhddevice 1.2.7-2
vdr-plugin-streamdev-client 0.6.1+git20180514-5
vdr-plugin-streamdev-server 0.6.1+git20180514-5
vdr-plugin-svdrposd 1.0.0-11
vdr-plugin-svdrpservice 1.0.0-10
vdr-plugin-vdrmanager   0.12+git20211220-2
vdr-plugin-vnsiserver   1:1.8.0+git20211205-2
vdr-plugin-wirbelscan   2021.12.11-3
vdr-plugin-xineliboutput2.2.0+git20211212-2
vdr 2.6.0-1~etobi1

BR,

Tobias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Marko Mäkelä]

Sat, Jan 01, 2022 at 06:44:52PM +0100, Narcis Garcia wrote:

As Far As I Know w-scan2 is needed to tune DVB-T2

https://github.com/stefantalpalaru/w_scan2/


Another DVB-T2 compatible solution (which also supports DVB-T) is 
t2scan.


This is how I built and invoked it on my Raspberry Pi 2 (using Debian, 
or 2 different most recent versions of Raspberry OS):


git clone https://github.com/mighty-p/t2scan
cd t2scan
./configure
make -j$(nproc)
./t2scan -E -d|tee channels.conf

Before this, I had to copy the firmware blob for the Astrometa DVB-T2 
adapter to /lib/firmware/dvb-demod-mn88473-01.fw and plug in the USB 
adapter. For some reason, that firmware is missing from Debian.


Without the firmware, the scan would fail with "no signal" on every 
channel.


The t2scan program is apparently using LANG or LC_CTYPE to guess the 
current country, which only works if the locale files have been built.  
The default (Germany) may be overridden with the -Y flag.


Marko

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Narcis Garcia]

As Far As I Know w-scan2 is needed to tune DVB-T2

https://github.com/stefantalpalaru/w_scan2/

What I don't know is how to do to manage TV tunning from Kodi interface.



Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

El 7/12/21 a les 9:40, Narcis Garcia ha escrit:

vdr-plugin-dvbhddevice
vdr-plugin-dvbsddevice
vdr-plugin-femon
vdr-plugin-live
vdr-plugin-osdserver
vdr-plugin-streamdev-client
vdr-plugin-streamdev-server
vdr-plugin-vnsiserver
w-scan2


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

El 7/12/21 a les 9:05, Reiner Buehl ha escrit:

Hello Tobi,

I use the following plugins on my Debian based VDR systems:

  vdr-plugin-epgsearch
  vdr-plugin-extrecmenu
  vdr-plugin-graphlcd
  vdr-plugin-markad-ng
  vdr-plugin-menuorg
  vdr-plugin-skinflatplus
  vdr-plugin-xineliboutput
  vdr-plugin-streamdev-*

Thanks for maintaining the packages!

Best regards,
Reiner

Am 2021-12-06 22:45, schrieb Tobi:

Hi!

To my shame, I have rather neglected the maintenance of the VDR and VDR
plugin packages for Debian and e-tobi.net over the last 2 years.
I am in the process of catching up. However, I would like to get rid of
some plugins where nothing is happening upstream anymore.
Which plugins do you consider indispensable and would like to see them
continue in the official Debian and/or e-tobi.net Debian repositories?

BR,

Tobias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Marko Mäkelä]

Wed, Dec 29, 2021 at 04:56:54PM +0200, René wrote:
Klaus just released 2.6.0. Any chance if we could get that version too? 
:-)


For me, git://projects.vdr-developer.org/vdr-plugin-rpihddevice.git 
would be a must-have feature.


Today I made an attempt of installing Debian Sid from the scratch on a 
new SD card, starting with https://wiki.debian.org/RaspberryPiImages and 
documenting the steps.


The non-obvious first steps (to enable system clock updates and make the 
system visible in the .local network) were as follows:


apt install systemd-timesyncd avahi-daemon
timedatectl set-ntp on

Tobias wrote:

Still on the TODO list are:

∙ vdr-plugin-rpihddevice

[snip]

For rpihddevice I'm not sure what to do - OMX and MMAL have been
deprecated in Raspbian/bullseye, so it doesn't even build out of the box.
And it doesn't look like a V4L2 version is being worked on.


Today, I was almost able to compile VDR 2.6.0 on Debian Sid with 
rpihddevice. First, the dependencies:


apt install build-essential git
apt install pkg-config gettext
apt install libfreetype6-dev libfontconfig1-dev libjpeg62-turbo-dev
apt install libcap-dev libncurses5-dev
apt install libavcodec-dev libavformat-dev

Then, as a normal user, execute the following:

git clone http://git.tvdr.de/vdr.git
git clone git://projects.vdr-developer.org/vdr-plugin-rpihddevice.git
ln -s ../../../vdr-plugin-rpihddevice vdr/PLUGINS/src/rpihddevice
make -C vdr -j$(nproc)

The build failed due to a missing header:

ilclient.c:50:10: fatal error: interface/vcos/vcos.h: No such file or directory

There are very few Raspberry specific packages in Debian. libbcm2835-dev 
is covering something else.


As far as I can tell, the file is provided by the Raspberry OS or Ubuntu 
package libraspberrypi-dev in /opt/vc/include or /usr/include, 
respectively. That package appears to be missing from Debian, even the 
non-free section.


Tobias, would it be possible to add these packages to Debian Sid?

https://github.com/raspberrypi/userland

I am not familiar with this, but I see that something in interface/vcos 
was changed only 2 months ago. Most of the files are years old, but so 
is my Raspberry Pi 2. I did not notice any deprecation message, but I 
suppose that you were referring to some other interface being 
deprecated.


The Ubuntu package could serve as a starting point:

https://packages.ubuntu.com/source/impish/raspberrypi-userland

My aim is to document the process of creating a minimal VDR installation 
on a Raspberry Pi. It would be great if all code were available out of 
the box.


For me, the "killer feature" would be custom configuration for making 
VDR automatically start up when the USB DVB adapter is plugged in. An 
unplugged adapter cannot waste electricity or let a lighting bolt kill 
the server.


Marko

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Andreas Kreuzinger]

Hi,

* Tobi  [2021-12-06 22:45]:

> To my shame, I have rather neglected the maintenance of the VDR and VDR
> plugin packages for Debian and e-tobi.net over the last 2 years.
> I am in the process of catching up. However, I would like to get rid of
> some plugins where nothing is happening upstream anymore.
> Which plugins do you consider indispensable and would like to see them
> continue in the official Debian and/or e-tobi.net Debian repositories?

I am using these (and it would be nice to have them or an equivalent):
vdr
vdradmin-am
vdr-markad
vdr-plugin-epgsearch
vdr-plugin-femon
vdr-plugin-remote
vdr-plugin-streamdev-server
vdr-plugin-svdrposd
vdr-plugin-vnsiserver
vdr-plugin-xineliboutput

Thank you for your work.  :)

mfg @ndy
-- 


signature.asc
Description: PGP signature
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net (Tobi)

[Richard F]

Heroic work - thanks, and Merry Xmas

Richard

On 22/12/2021 12:00, vdr-requ...@linuxtv.org wrote:


Today's Topics:

1. Re: VDR packages in Debian and e-tobi.net (Tobi)

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Tobi]

So far, I've updated the following packages in debian/sid, which soon will
migrate to debian/testing:

∙ vdr 2.4.7
∙ vdr-plugin-dvd 0.3.6~b03+git20211216
∙ vdr-plugin-dvbhddevice 2.2.0
∙ vdr-plugin-dvbsddevice 2.2.0
∙ vdr-plugin-epgsearch 2.4.1
∙ vdr-plugin-epgsync 1.0.1
∙ vdr-plugin-femon 2.4.0
∙ vdr-plugin-live 3.1.3
∙ vdr-plugin-osdserver 0.1.3
∙ vdr-plugin-osdteletext 2.3.0
∙ vdr-plugin-remote 0.7.0
∙ vdr-plugin-satip 2.4.1
∙ vdr-plugin-skinenigmang 0.1.2+git20190720
∙ vdr-plugin-streamdev 0.6.1+git20180514
∙ vdr-plugin-svdrposd 1.0.0
∙ vdr-plugin-svdrpservice 1.0.0
∙ vdr-plugin-vnsiserver 1:1.8.0+git20211205-1
∙ vdr-plugin-xineliboutput 2.2.0+git20211212-1

For vnsiserver I use the original version from FernetMenta, not the fork
from mdre77, which seems to be more up to date. But as the original
version works fine for me, I will stay with it, until someone can convince
me to switch to the fork.

Additionally to these packages, the following plugins are also available
in my private repository:

deb https://packages.e-tobi.net/vdr-experimental bullseye base
vdr-multipatch addons

∙ vdr-plugin-dummydevice 2.0.0
∙ vdr-plugin-epg2vdr 1.1.118
∙ vdr-plugin-femon 2.4.0
∙ vdr-plugin-fritzbox 1.5.4
∙ vdr-plugin-graphlcd 1.0.6
∙ vdr-plugin-iptv 2.4.0
∙ vdr-plugin-menuorg 0.5.2
∙ vdr-plugin-noepg 0.0.5
∙ vdr-plugin-pvrinput 2015-11-07
∙ vdr-plugin-skinelchi 0.3.0
∙ vdr-plugin-skinflatplus 0.6.1
∙ vdr-plugin-skinsoppalusikka 2.4.0
∙ vdr-plugin-softhddevice 1.2.6
∙ vdr-plugin-vdrmanager 0.12+git20211220
∙ vdr-plugin-wirbelscan 2021.12.11

Still on the TODO list are:

∙ vdr-plugin-rpihddevice
∙ vdr-plugin-markad or markad-ng
∙ vdr-plugin-extrecmenu or extrecmenung
∙ vdr-plugin-yaepghd
∙ vdr-plugin-vaapidevice
∙ vdr-plugin-undelete
∙ vdr-plugin-tvguide
∙ vdr-plugin-trayopenng
∙ vdr-plugin-suspendoutput
∙ vdr-plugin-osdpip
∙ vdr-plugin-noepg
∙ vdr-plugin-loadepg
∙ vdr-plugin-cdplayer
∙ vdr-plugin-skindesigner
∙ vdr-plugin-imonlcd

For rpihddevice I'm not sure what to do - OMX and MMAL have been
deprecated in Raspbian/bullseye, so it doesn't even build out of the box.
And it doesn't look like a V4L2 version is being worked on.

For undelete I'm thinking about applying this patch instead:

https://www.vdr-portal.de/forum/index.php?thread/132378-vdr-2-4-x-und-undelete/

Maybe Klaus can consider this for 2.5.x/2.6.x.

I can't test all these plugins. The only plugins I really use, are
vnsiserver, epgsearch and rarely xineliboutput and femon.

BR,
Tobias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Udo Richter]

On 13.12.21 00:28, Tobi wrote:

I hope to have at least have the top 20 plugin packages updated by the end
of the year.


If you need help with any of my old plugins or patches, let me know.

Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Tobi]

Thanks for your suggesstions!

I hope to have at least have the top 20 plugin packages updated by the end
of the year.

Packages will be updated in debian/unstable first.

BR,

Tobias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Matthias Maisenbacher]

> I am in the process of catching up.
That sounds great.

> Which plugins do you consider indispensable and would like to see them
> continue in the official Debian and/or e-tobi.net Debian repositories?
I'd really like to see undelete again
(Or any other plugin with that functionality)

Thank you for your work.

  Matthias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Torgeir Veimo]

Having VDR running natively on android would be nice, but there's no
v4l there. Did you try robotv with the livechannels app? It works
fairly well, but it's not the native VDR OSD, and there's dropout from
time to time.

On Thu, 9 Dec 2021 at 18:17, Karl-Heinz Volk  wrote:
>
> Nice to hear that you are planning a new repository:
>
> vdr-plugin-streamdev-client
> vdr-plugin-streamdev-server
> vdr-plugin-softhddevice
> vdr-plugin-rpihddevice
> vdr-plugin-vaapidevice
>
> And is it really so far away, to have a vdr for Android-TV? I own a Sony 
> 43X8309C. 6 Years old and only usable with a Firetv-Stick...
>
> Viele Grüße
>   Karl-Heinz
>
>
>
> Am Mi., 8. Dez. 2021 um 16:41 Uhr schrieb Piotr Długosz :
>>
>> Thank you Tobias for your work!
>>
>> I'm using VDR with:
>>
>> vdr-plugin-epgsearch
>> vdr-plugin-femon
>> vdr-plugin-live
>> vdr-plugin-skinelchi
>> vdr-plugin-streamdev-client
>> vdr-plugin-streamdev-server
>> vdr-plugin-svdrposd
>> vdr-plugin-tvguide
>> vdr-plugin-vdrmanager
>> vdr-plugin-xineliboutput
>>
>> However, I would happily change the skin plugin because skinelchi is in
>> use for >10 years already ;-) Only I have to find nicer skin working
>> well on obsolete Full HD TV...
>>
>> Best regards,
>> Piotr
>>
>> W dniu pon, 06.12.2021 o godzinie 22∶45 +0100, użytkownik Tobi napisał:
>> > Hi!
>> >
>> > To my shame, I have rather neglected the maintenance of the VDR and
>> > VDR
>> > plugin packages for Debian and e-tobi.net over the last 2 years.
>> > I am in the process of catching up. However, I would like to get rid
>> > of
>> > some plugins where nothing is happening upstream anymore.
>> > Which plugins do you consider indispensable and would like to see
>> > them
>> > continue in the official Debian and/or e-tobi.net Debian
>> > repositories?
>> >
>> > BR,
>> >
>> > Tobias
>> >
>> > ___
>> > vdr mailing list
>> > vdr@linuxtv.org
>> > https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
>
> --
> Karl-Heinz Volk
> Pastorenweg 78 B
> 28237 Bremen
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
-Tor

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Karl-Heinz Volk]

Nice to hear that you are planning a new repository:

vdr-plugin-streamdev-client
vdr-plugin-streamdev-server
vdr-plugin-softhddevice
vdr-plugin-rpihddevice
vdr-plugin-vaapidevice

And is it really so far away, to have a vdr for Android-TV? I own a Sony
43X8309C. 6 Years old and only usable with a Firetv-Stick...

Viele Grüße
  Karl-Heinz



Am Mi., 8. Dez. 2021 um 16:41 Uhr schrieb Piotr Długosz :

> Thank you Tobias for your work!
>
> I'm using VDR with:
>
> vdr-plugin-epgsearch
> vdr-plugin-femon
> vdr-plugin-live
> vdr-plugin-skinelchi
> vdr-plugin-streamdev-client
> vdr-plugin-streamdev-server
> vdr-plugin-svdrposd
> vdr-plugin-tvguide
> vdr-plugin-vdrmanager
> vdr-plugin-xineliboutput
>
> However, I would happily change the skin plugin because skinelchi is in
> use for >10 years already ;-) Only I have to find nicer skin working
> well on obsolete Full HD TV...
>
> Best regards,
> Piotr
>
> W dniu pon, 06.12.2021 o godzinie 22∶45 +0100, użytkownik Tobi napisał:
> > Hi!
> >
> > To my shame, I have rather neglected the maintenance of the VDR and
> > VDR
> > plugin packages for Debian and e-tobi.net over the last 2 years.
> > I am in the process of catching up. However, I would like to get rid
> > of
> > some plugins where nothing is happening upstream anymore.
> > Which plugins do you consider indispensable and would like to see
> > them
> > continue in the official Debian and/or e-tobi.net Debian
> > repositories?
> >
> > BR,
> >
> > Tobias
> >
> > ___
> > vdr mailing list
> > vdr@linuxtv.org
> > https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>


-- 
Karl-Heinz Volk
Pastorenweg 78 B
28237 Bremen
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Piotr Długosz]

Thank you Tobias for your work!

I'm using VDR with:

vdr-plugin-epgsearch   
vdr-plugin-femon   
vdr-plugin-live
vdr-plugin-skinelchi   
vdr-plugin-streamdev-client
vdr-plugin-streamdev-server
vdr-plugin-svdrposd
vdr-plugin-tvguide 
vdr-plugin-vdrmanager  
vdr-plugin-xineliboutput   

However, I would happily change the skin plugin because skinelchi is in
use for >10 years already ;-) Only I have to find nicer skin working
well on obsolete Full HD TV...

Best regards,
Piotr

W dniu pon, 06.12.2021 o godzinie 22∶45 +0100, użytkownik Tobi napisał:
> Hi!
> 
> To my shame, I have rather neglected the maintenance of the VDR and
> VDR
> plugin packages for Debian and e-tobi.net over the last 2 years.
> I am in the process of catching up. However, I would like to get rid
> of
> some plugins where nothing is happening upstream anymore.
> Which plugins do you consider indispensable and would like to see
> them
> continue in the official Debian and/or e-tobi.net Debian
> repositories?
> 
> BR,
> 
> Tobias
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Patrick Cernko]

Hi Tobi,

I'm using

vdr
vdr-plugin-epgsearch
vdr-plugin-extrecmenung (from https://gitlab.com/kamel5/extrecmenung)
vdr-plugin-femon
vdr-plugin-live
vdr-plugin-osdteletext
vdr-plugin-streamdev-server
vdr-plugin-xineliboutput (from deb-multimedia.org)
vdradmin-am

on my vdr running as headless server and xineliboutput-sxfe (from 
deb-multimedia.org) on my Viewer-Client.


Best,
--
Patrick Cernko | mailto:err...@errror.org | http://www.errror.org



smime.p7s
Description: S/MIME Cryptographic Signature
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Narcis Garcia]

vdr-plugin-dvbhddevice
vdr-plugin-dvbsddevice
vdr-plugin-femon
vdr-plugin-live
vdr-plugin-osdserver
vdr-plugin-streamdev-client
vdr-plugin-streamdev-server
vdr-plugin-vnsiserver
w-scan2


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

El 7/12/21 a les 9:05, Reiner Buehl ha escrit:

Hello Tobi,

I use the following plugins on my Debian based VDR systems:

  vdr-plugin-epgsearch
  vdr-plugin-extrecmenu
  vdr-plugin-graphlcd
  vdr-plugin-markad-ng
  vdr-plugin-menuorg
  vdr-plugin-skinflatplus
  vdr-plugin-xineliboutput
  vdr-plugin-streamdev-*

Thanks for maintaining the packages!

Best regards,
Reiner

Am 2021-12-06 22:45, schrieb Tobi:

Hi!

To my shame, I have rather neglected the maintenance of the VDR and VDR
plugin packages for Debian and e-tobi.net over the last 2 years.
I am in the process of catching up. However, I would like to get rid of
some plugins where nothing is happening upstream anymore.
Which plugins do you consider indispensable and would like to see them
continue in the official Debian and/or e-tobi.net Debian repositories?

BR,

Tobias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR packages in Debian and e-tobi.net

[Reiner Buehl]

Hello Tobi,

I use the following plugins on my Debian based VDR systems:

 vdr-plugin-epgsearch
 vdr-plugin-extrecmenu
 vdr-plugin-graphlcd
 vdr-plugin-markad-ng
 vdr-plugin-menuorg
 vdr-plugin-skinflatplus
 vdr-plugin-xineliboutput
 vdr-plugin-streamdev-*

Thanks for maintaining the packages!

Best regards,
Reiner

Am 2021-12-06 22:45, schrieb Tobi:

Hi!

To my shame, I have rather neglected the maintenance of the VDR and VDR
plugin packages for Debian and e-tobi.net over the last 2 years.
I am in the process of catching up. However, I would like to get rid of
some plugins where nothing is happening upstream anymore.
Which plugins do you consider indispensable and would like to see them
continue in the official Debian and/or e-tobi.net Debian repositories?

BR,

Tobias

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


--
--
Reiner Bühl  Internet:
Karlstrasse 3rei...@buehl.net
70771 Leinfelden-Echterdingen
Germany
--


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/20 a les 14:11, Helmut Binder ha escrit:
>> $ ls -la /dev/dvb/adapter0/
>> total 0
>> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
>> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
>> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
>> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
>> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
>> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
>> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
>>
> This is a multi-frontend device. You need VDR-2.4.1 or newer - or at least 
> this patch from here:
> https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966

I've just tried same device with Ubuntu 20.10 (it has VDR 2.4.1 on
repositories)
This is not fixed in this version.
I had to do the frontend0 <-> frontend1 workaround to have it working
(channels scan must be done without frontends swap). And no EPG.
Same results as with Raspbian 10


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 22:13, Helmut Binder ha escrit:
> 
> Can you receive any DVB-T2 Channels ? These would use frontend 0/1 with the 
> CXD2837ER demodulator and you could compare the tuning.
> If not, rename frontend1 to frontend0, similar as in Timo's proposal:
> 
> - stop vdr
>  > mv /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/Xfrontend0"
>  > mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0"
> - start vdr
> 
> Helmut
> 

Tried this workaround several times, and last one resulted but in this
order:

1. Tuned channels with devices/frontends "as is"
2. moved frontend1 to frontend0

I'm pending to do more testing and be sure this is the point for my case.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

A simplified alternative to w_scan2:

https://github.com/mighty-p/t2scan/


Narcis Garcia

El 1/12/20 a les 8:50, Narcis Garcia ha escrit:
> The project sources repository (sadly in a proprietary platform):
> 
> https://github.com/stefantalpalaru/w_scan2
> 
> 
> 
> Narcis Garcia
> 
> El 30/11/20 a les 19:47, Richard F ha escrit:
>> Thanks by the way for the heads-up on w_scan2 - the fork of w_scan I
>> didn't know about.  As an external tool, that now tunes DVB-T2 HD 
>> channels for me at last - the only thing outside VDR itself that works
>> so far :-)
>>
>> Richard
>>
>> On 29/11/2020 2:16 pm, Timo Helkiö wrote:
>>> Timo Helkiö kirjoitti 29.11.2020 klo 16.09:
 Helmut Binder kirjoitti 29.11.2020 klo 15.11:
> On Sat, 28 Nov 2020 17:44:32 +0100
> Narcis Garcia  wrote:
>> _
>> I'm using this dedicated address because personal addresses aren't
>> masked enough at this mail public archive. Public archive
>> administrator
>> should fix this against automated addresses collectors.
>> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
>>> On 28.11.20 17:30, Narcis Garcia wrote:
 Hello,

 I've installed vdr from Raspbian packages, to use it with Kodi.
 I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
 channels are found.

 But I try to watch some channel and I get no data.
>>>
>>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Richard F]

I cloned it and built it from that source on OpenSuSe 15.2, no problem
(well quite a few warnings...!)

On 1/12/2020 7:50 am, Narcis Garcia wrote:
> The project sources repository (sadly in a proprietary platform):
>
> https://github.com/stefantalpalaru/w_scan2
>
>
> Narcis Garcia
>
> El 30/11/20 a les 19:47, Richard F ha escrit:
>> Thanks by the way for the heads-up on w_scan2 - the fork of w_scan I
>> didn't know about.  As an external tool, that now tunes DVB-T2 HD 
>> channels for me at last - the only thing outside VDR itself that works
>> so far :-)
>>
>> Richard
>>
>>

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

The project sources repository (sadly in a proprietary platform):

https://github.com/stefantalpalaru/w_scan2



Narcis Garcia

El 30/11/20 a les 19:47, Richard F ha escrit:
> Thanks by the way for the heads-up on w_scan2 - the fork of w_scan I
> didn't know about.  As an external tool, that now tunes DVB-T2 HD 
> channels for me at last - the only thing outside VDR itself that works
> so far :-)
> 
> Richard
> 
> On 29/11/2020 2:16 pm, Timo Helkiö wrote:
>> Timo Helkiö kirjoitti 29.11.2020 klo 16.09:
>>> Helmut Binder kirjoitti 29.11.2020 klo 15.11:
 On Sat, 28 Nov 2020 17:44:32 +0100
 Narcis Garcia  wrote:
> _
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive
> administrator
> should fix this against automated addresses collectors.
> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
>> On 28.11.20 17:30, Narcis Garcia wrote:
>>> Hello,
>>>
>>> I've installed vdr from Raspbian packages, to use it with Kodi.
>>> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
>>> channels are found.
>>>
>>> But I try to watch some channel and I get no data.
>>
>>
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Richard F]

Thanks by the way for the heads-up on w_scan2 - the fork of w_scan I
didn't know about.  As an external tool, that now tunes DVB-T2 HD 
channels for me at last - the only thing outside VDR itself that works
so far :-)

Richard

On 29/11/2020 2:16 pm, Timo Helkiö wrote:
> Timo Helkiö kirjoitti 29.11.2020 klo 16.09:
>> Helmut Binder kirjoitti 29.11.2020 klo 15.11:
>>> On Sat, 28 Nov 2020 17:44:32 +0100
>>> Narcis Garcia  wrote:
 _
 I'm using this dedicated address because personal addresses aren't
 masked enough at this mail public archive. Public archive
 administrator
 should fix this against automated addresses collectors.
 El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
> On 28.11.20 17:30, Narcis Garcia wrote:
>> Hello,
>>
>> I've installed vdr from Raspbian packages, to use it with Kodi.
>> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
>> channels are found.
>>
>> But I try to watch some channel and I get no data.
>
>

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 22:13, Helmut Binder ha escrit:
> On Sun, 29 Nov 2020 17:53:27 +0100
> Narcis Garcia  wrote:
> 
>> El 29/11/20 a les 15:09, Timo Helkiö ha escrit:
>>> Helmut Binder kirjoitti 29.11.2020 klo 15.11:
 On Sat, 28 Nov 2020 17:44:32 +0100
 Narcis Garcia  wrote:

> _
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
>> On 28.11.20 17:30, Narcis Garcia wrote:
>>> Hello,
>>>
>>> I've installed vdr from Raspbian packages, to use it with Kodi.
>>> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
>>> channels are found.
>>>
>>> But I try to watch some channel and I get no data.
>>
>> Does the user id under which you run VDR have access to the
>> DVB devices?
>>
>> Klaus
>>
>
> $ ls -la /dev/dvb/adapter0/
> total 0
> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
>

 This is a multi-frontend device. You need VDR-2.4.1 or newer - or at
 least this patch from here:
 https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966


 Helmut
>>
>> I've done this like a backport from next Raspbian version:
>>
>> $ sudo apt -t bullseye install vdr
>>
>> /[installing new] gcc-10-base libcbor0 libcrypt-dev libcrypt1 libffi7
>> libfido2-1 libgcc-s1 libnsl-dev libnsl2 libnss-nis libnss-nisplus
>> libreadline8 libtirpc-dev runit-helper/
>>
>> /[upgrading] libc-bin libc-dev-bin libc-l10n libc6 libc6-dbg libc6-dev
>> libpython3.7 libpython3.7-dev libpython3.7-minimal libpython3.7-stdlib
>> libselinux1 libstdc++6 libtirpc-common libtirpc3 locales manpages
>> manpages-dev openssh-client openssh-server openssh-sftp-server python3.7
>> python3.7-dev python3.7-minimal python3.7-venv vdr vdr-plugin-femon
>> vdr-plugin-live vdr-plugin-osdserver vdr-plugin-vnsiserver/
>>
>> (...) Bai:43 http://ftp.cica.es/mirrors/Linux/raspbian/raspbian
>> bullseye/main armhf vdr armhf 2.4.1-4.1 [1043 kB] S'està preparant per a
>> desempaquetar …/vdr_2.4.1-4.1_armhf.deb… S'està desempaquetant vdr
>> (2.4.1-4.1) sobre (2.4.0-1+b1)… (...)
>>
>> $ sudo systemctl stop vdr
>>
>> $ sudo systemctl start vdr
>>
>> $ sudo journalctl -xef -u vdr
>>
>> de nov. 29 17:41:31 raspberrypi systemd[1]: Starting Video Disk Recorder...
>> -- Subject: A start job for unit vdr.service has begun execution
>> -- Defined-By: systemd
>> -- Support: https://www.debian.org/support
>> -- 
>> -- A start job for unit vdr.service has begun execution.
>> -- 
>> -- The job identifier is 867922.
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] VDR version 2.4.1
>> started
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] switched to user 'vdr'
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] codeset is 'UTF-8' -
>> known
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] found 28 locales in
>> /usr/share/locale
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
>> /usr/lib/vdr/plugins/libvdr-femon.so.2.4.1
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
>> /usr/lib/vdr/plugins/libvdr-live.so.2.4.1
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] [live] INFO:
>> validating server ip '0.0.0.0'
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
>> /usr/lib/vdr/plugins/libvdr-osdserver.so.2.4.1
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: INFO: validating live server
>> ip '0.0.0.0'
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
>> /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.1
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/setup.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/sources.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/diseqc.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/scr.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/channels.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/timers.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/commands.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> /var/lib/vdr/reccmds.conf
>> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
>> 

Re: [vdr] vdr not working in Raspbian 10

[Helmut Binder]

On Sun, 29 Nov 2020 17:53:27 +0100
Narcis Garcia  wrote:

> El 29/11/20 a les 15:09, Timo Helkiö ha escrit:
> > Helmut Binder kirjoitti 29.11.2020 klo 15.11:
> >> On Sat, 28 Nov 2020 17:44:32 +0100
> >> Narcis Garcia  wrote:
> >>
> >>> _
> >>> I'm using this dedicated address because personal addresses aren't
> >>> masked enough at this mail public archive. Public archive administrator
> >>> should fix this against automated addresses collectors.
> >>> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
>  On 28.11.20 17:30, Narcis Garcia wrote:
> > Hello,
> >
> > I've installed vdr from Raspbian packages, to use it with Kodi.
> > I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
> > channels are found.
> >
> > But I try to watch some channel and I get no data.
> 
>  Does the user id under which you run VDR have access to the
>  DVB devices?
> 
>  Klaus
> 
> >>>
> >>> $ ls -la /dev/dvb/adapter0/
> >>> total 0
> >>> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
> >>> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
> >>> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
> >>> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
> >>> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
> >>> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
> >>> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
> >>>
> >>
> >> This is a multi-frontend device. You need VDR-2.4.1 or newer - or at
> >> least this patch from here:
> >> https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966
> >>
> >>
> >> Helmut
> 
> I've done this like a backport from next Raspbian version:
> 
> $ sudo apt -t bullseye install vdr
> 
> /[installing new] gcc-10-base libcbor0 libcrypt-dev libcrypt1 libffi7
> libfido2-1 libgcc-s1 libnsl-dev libnsl2 libnss-nis libnss-nisplus
> libreadline8 libtirpc-dev runit-helper/
> 
> /[upgrading] libc-bin libc-dev-bin libc-l10n libc6 libc6-dbg libc6-dev
> libpython3.7 libpython3.7-dev libpython3.7-minimal libpython3.7-stdlib
> libselinux1 libstdc++6 libtirpc-common libtirpc3 locales manpages
> manpages-dev openssh-client openssh-server openssh-sftp-server python3.7
> python3.7-dev python3.7-minimal python3.7-venv vdr vdr-plugin-femon
> vdr-plugin-live vdr-plugin-osdserver vdr-plugin-vnsiserver/
> 
> (...) Bai:43 http://ftp.cica.es/mirrors/Linux/raspbian/raspbian
> bullseye/main armhf vdr armhf 2.4.1-4.1 [1043 kB] S'està preparant per a
> desempaquetar …/vdr_2.4.1-4.1_armhf.deb… S'està desempaquetant vdr
> (2.4.1-4.1) sobre (2.4.0-1+b1)… (...)
> 
> $ sudo systemctl stop vdr
> 
> $ sudo systemctl start vdr
> 
> $ sudo journalctl -xef -u vdr
> 
> de nov. 29 17:41:31 raspberrypi systemd[1]: Starting Video Disk Recorder...
> -- Subject: A start job for unit vdr.service has begun execution
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> -- 
> -- A start job for unit vdr.service has begun execution.
> -- 
> -- The job identifier is 867922.
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] VDR version 2.4.1
> started
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] switched to user 'vdr'
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] codeset is 'UTF-8' -
> known
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] found 28 locales in
> /usr/share/locale
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
> /usr/lib/vdr/plugins/libvdr-femon.so.2.4.1
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
> /usr/lib/vdr/plugins/libvdr-live.so.2.4.1
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] [live] INFO:
> validating server ip '0.0.0.0'
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
> /usr/lib/vdr/plugins/libvdr-osdserver.so.2.4.1
> de nov. 29 17:41:31 raspberrypi vdr[26842]: INFO: validating live server
> ip '0.0.0.0'
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
> /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.1
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/setup.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/sources.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/diseqc.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/scr.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/channels.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/timers.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/commands.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/reccmds.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/svdrphosts.conf
> de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
> /var/lib/vdr/keymacros.conf
> de nov. 

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 15:09, Timo Helkiö ha escrit:
> Helmut Binder kirjoitti 29.11.2020 klo 15.11:
>> On Sat, 28 Nov 2020 17:44:32 +0100
>> Narcis Garcia  wrote:
>>
>>> _
>>> I'm using this dedicated address because personal addresses aren't
>>> masked enough at this mail public archive. Public archive administrator
>>> should fix this against automated addresses collectors.
>>> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
 On 28.11.20 17:30, Narcis Garcia wrote:
> Hello,
>
> I've installed vdr from Raspbian packages, to use it with Kodi.
> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
> channels are found.
>
> But I try to watch some channel and I get no data.

 Does the user id under which you run VDR have access to the
 DVB devices?

 Klaus

>>>
>>> $ ls -la /dev/dvb/adapter0/
>>> total 0
>>> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
>>> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
>>> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
>>> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
>>> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
>>> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
>>> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
>>>
>>
>> This is a multi-frontend device. You need VDR-2.4.1 or newer - or at
>> least this patch from here:
>> https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966
>>
>>
>> Helmut

I've done this like a backport from next Raspbian version:

$ sudo apt -t bullseye install vdr

/[installing new] gcc-10-base libcbor0 libcrypt-dev libcrypt1 libffi7
libfido2-1 libgcc-s1 libnsl-dev libnsl2 libnss-nis libnss-nisplus
libreadline8 libtirpc-dev runit-helper/

/[upgrading] libc-bin libc-dev-bin libc-l10n libc6 libc6-dbg libc6-dev
libpython3.7 libpython3.7-dev libpython3.7-minimal libpython3.7-stdlib
libselinux1 libstdc++6 libtirpc-common libtirpc3 locales manpages
manpages-dev openssh-client openssh-server openssh-sftp-server python3.7
python3.7-dev python3.7-minimal python3.7-venv vdr vdr-plugin-femon
vdr-plugin-live vdr-plugin-osdserver vdr-plugin-vnsiserver/

(...) Bai:43 http://ftp.cica.es/mirrors/Linux/raspbian/raspbian
bullseye/main armhf vdr armhf 2.4.1-4.1 [1043 kB] S'està preparant per a
desempaquetar …/vdr_2.4.1-4.1_armhf.deb… S'està desempaquetant vdr
(2.4.1-4.1) sobre (2.4.0-1+b1)… (...)

$ sudo systemctl stop vdr

$ sudo systemctl start vdr

$ sudo journalctl -xef -u vdr

de nov. 29 17:41:31 raspberrypi systemd[1]: Starting Video Disk Recorder...
-- Subject: A start job for unit vdr.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit vdr.service has begun execution.
-- 
-- The job identifier is 867922.
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] VDR version 2.4.1
started
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] switched to user 'vdr'
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] codeset is 'UTF-8' -
known
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] found 28 locales in
/usr/share/locale
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
/usr/lib/vdr/plugins/libvdr-femon.so.2.4.1
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
/usr/lib/vdr/plugins/libvdr-live.so.2.4.1
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] [live] INFO:
validating server ip '0.0.0.0'
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
/usr/lib/vdr/plugins/libvdr-osdserver.so.2.4.1
de nov. 29 17:41:31 raspberrypi vdr[26842]: INFO: validating live server
ip '0.0.0.0'
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading plugin:
/usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.1
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/setup.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/sources.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/diseqc.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/scr.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/channels.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/timers.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/commands.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/reccmds.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/svdrphosts.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] loading
/var/lib/vdr/keymacros.conf
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26843] video directory
scanner thread started (pid=26842, tid=26843, prio=low)
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26842] registered source
parameters for 'A - ATSC'
de nov. 29 17:41:31 raspberrypi vdr[26842]: [26844] epg data reader
thread 

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 15:09, Timo Helkiö ha escrit:
> Helmut Binder kirjoitti 29.11.2020 klo 15.11:
>> On Sat, 28 Nov 2020 17:44:32 +0100
>> Narcis Garcia  wrote:
>>
>>> _
>>> I'm using this dedicated address because personal addresses aren't
>>> masked enough at this mail public archive. Public archive administrator
>>> should fix this against automated addresses collectors.
>>> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
 On 28.11.20 17:30, Narcis Garcia wrote:
> Hello,
>
> I've installed vdr from Raspbian packages, to use it with Kodi.
> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
> channels are found.
>
> But I try to watch some channel and I get no data.

 Does the user id under which you run VDR have access to the
 DVB devices?

 Klaus

>>>
>>> $ ls -la /dev/dvb/adapter0/
>>> total 0
>>> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
>>> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
>>> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
>>> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
>>> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
>>> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
>>> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
>>>
>>
>> This is a multi-frontend device. You need VDR-2.4.1 or newer - or at
>> least this patch from here:
>> https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966
>>
>>
>> Helmut
>>
>>> $ ps -A -o user,group,cmd | grep -ie vdr
>>> vdradmi+ vdradmi+ vdradmind
>>> pi   pi   grep --color=auto -ie vdr
>>> vdr  vdr  /usr/bin/vdr
>>>
>>> $ groups vdr
>>> vdr : vdr video
>>>
>>> I'm trying now with vdr-plugin-live : Same unsuccess result.
>>>
>>> ___
>>> vdr mailing list
>>> vdr@linuxtv.org
>>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> 
> 
> You need to select correct frontend like this:
> 
> #!/bin/bash
> 
> var=$(dvb-fe-tool -a0 -f1 | grep 'Device' | awk '{print $3}')
> 
> echo 'A0 Second frontend is ' $var
> 
> if [ $var == 'MN88473' ]; then
> 
> echo 'A0 frontend is ' $var
> 
> mv /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend2
> mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0
> mv /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/frontend1
> 
> fi
> 
> var=$(dvb-fe-tool -a0 -f0 | grep 'Device' | awk '{print $3}')
> 
> if [ $var == 'MN88473' ]; then
> 
> dvb-fe-tool -a0 -f0 -d DVBT2
> 
> dvb-fe-tool -a0 -f0 -g |grep DELIVERY
> 
> fi
> 
> 
> Second frontend with this adapter can handle DVBC/ANNEX_A too.
> 
> Vdr should know both frontends and use correct one and setup delivery
> system either by setup parameter or trying which one is working and
> prefer DVBT2. With satelite channnels it knows when to use S2. W_scan
> can handle this too.
> 
> Other version of this device can have CXD2837ER as second frontend name.
> 
> Timo
> 

Not matching cases:
Once I've installed dvb-tools to have dvb-fe-tool program:
$ sudo systemctl stop vdr
$ dvb-fe-tool -a0 -f1 | grep 'Device' | awk '{print $3}'
CXD2837ER
$ dvb-fe-tool -a0 -f0 | grep 'Device' | awk '{print $3}'
RTL2832
$ sudo systemctl start vdr

This is the assembled device:
https://osmc.tv/store/product/tv-dongle/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 14:16, André Weidemann ha escrit:
>
>
> On 29.11.2020 11:33, Narcis Garcia wrote:
>> de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] ERROR
>> (dvbdevice.c,1650): /dev/dvb/adapter0/frontend1: El dispositiu o recurs
>> es troba ocupat
>
> Looks like the dvb-adapter is already in use.
> You can try to figure which process is holding on to it by running:
>
> sudo lsof |grep /dev/dvb/adap|awk '{print $2}'|uniq|xargs ps -fp
>
> André

$ sudo lsof |grep /dev/dvb/adap|awk '{print $2}'|uniq|xargs ps -fp
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
UID    PID  PPID  C STIME TTY  TIME CMD
vdr  11391 1  0 11:29 ?    00:01:10 /usr/bin/vdr

*Narcís*


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 11:44, Klaus Schmidinger ha escrit:
> On 29.11.20 11:33, Narcis Garcia wrote:
>> ...
>> de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] ERROR
>> (dvbdevice.c,1650): /dev/dvb/adapter0/frontend1: El dispositiu o
>> recurs es troba ocupat
> 
> If this error message was given in English I might be able to interpret it.
> 
> Klaus
> 

"Device or resource is busy"


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 29/11/20 a les 9:42, Narcis Garcia ha escrit:
> El 28/11/20 a les 23:01, Klaus Schmidinger ha escrit:
>> On 28.11.20 17:55, Narcis Garcia wrote:
>>> ...
>>> de nov. 28 17:33:12 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
>>> lock on channel 23 (Telecinco), tp 586
>>> de nov. 28 17:33:13 raspberrypi vdr[30508]: [30514] frontend 0/0
>>> regained lock on channel 23 (Telecinco), tp 586
>> Maybe a bad cable/connector?
>>
>> Klaus
>>
> Should not, because Kaffeine app lets watch TV (with VDR stopped).
> Narcís.

I've used "VDR Live" to restart service while tracking log with
"journalctl -xef -u vdr"

*LOG:*

de nov. 29 11:29:47 raspberrypi systemd[1]: Starting Video Disk Recorder...
-- Subject: A start job for unit vdr.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit vdr.service has begun execution.
-- 
-- The job identifier is 222785.
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] VDR version 2.4.0
started
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] switched to user 'vdr'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] codeset is 'UTF-8' -
known
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] found 28 locales in
/usr/share/locale
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading plugin:
/usr/lib/vdr/plugins/libvdr-femon.so.2.4.0
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading plugin:
/usr/lib/vdr/plugins/libvdr-live.so.2.4.0
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] [live] INFO:
validating server ip '0.0.0.0'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading plugin:
/usr/lib/vdr/plugins/libvdr-osdserver.so.2.4.0
de nov. 29 11:29:47 raspberrypi vdr[11391]: INFO: validating live server
ip '0.0.0.0'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading plugin:
/usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.0
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/setup.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/sources.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/diseqc.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/scr.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/channels.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/timers.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/commands.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/reccmds.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/svdrphosts.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] loading
/var/lib/vdr/keymacros.conf
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11392] video directory
scanner thread started (pid=11391, tid=11392, prio=low)
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] registered source
parameters for 'A - ATSC'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] registered source
parameters for 'C - DVB-C'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11393] epg data reader
thread started (pid=11391, tid=11393, prio=high)
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] registered source
parameters for 'S - DVB-S'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11393] reading EPG data
from /var/cache/vdr/epg.data
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] registered source
parameters for 'T - DVB-T'
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11392] video directory
scanner thread ended (pid=11391, tid=11392)
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11393] epg data reader
thread ended (pid=11391, tid=11393)
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] probing
/dev/dvb/adapter0/frontend0
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] creating cDvbDevice
de nov. 29 11:29:47 raspberrypi vdr[11391]: [11391] new device number 1
de nov. 29 11:29:48 raspberrypi vdr[11391]: [11391] DVB API version is
0x050B (VDR was built with 0x050B)
de nov. 29 11:29:48 raspberrypi vdr[11391]: [11391] frontend 0/0
provides DVB-T with QPSK,QAM16,QAM64 ("Realtek RTL2832 (DVB-T)")
de nov. 29 11:29:48 raspberrypi vdr[11391]: [11397] frontend 0/0 tuner
thread started (pid=11391, tid=11397, prio=high)
de nov. 29 11:29:48 raspberrypi vdr[11391]: [11397] cTimeMs: using
monotonic clock (resolution is 1 ns)
de nov. 29 11:29:48 raspberrypi vdr[11391]: [11391] cTimeMs: using
monotonic clock (resolution is 1 ns)
de nov. 29 11:29:48 raspberrypi vdr[11391]: [11398] device 1 section
handler thread started (pid=11391, tid=11398, prio=low)
de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] ERROR
(dvbdevice.c,1650): /dev/dvb/adapter0/frontend1: El dispositiu o recurs
es troba ocupat
de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] found 1 DVB device
de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] initializing plugin:
femon (2.4.0): DVB Signal Information Monitor (OSD)
de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] 

Re: [vdr] vdr not working in Raspbian 10

[Timo Helkiö]

Timo Helkiö kirjoitti 29.11.2020 klo 16.09:

Helmut Binder kirjoitti 29.11.2020 klo 15.11:

On Sat, 28 Nov 2020 17:44:32 +0100
Narcis Garcia  wrote:


_
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:

On 28.11.20 17:30, Narcis Garcia wrote:

Hello,

I've installed vdr from Raspbian packages, to use it with Kodi.
I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
channels are found.

But I try to watch some channel and I get no data.


Does the user id under which you run VDR have access to the
DVB devices?

Klaus



$ ls -la /dev/dvb/adapter0/
total 0
drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0



This is a multi-frontend device. You need VDR-2.4.1 or newer - or at 
least this patch from here:
https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966 



Helmut


$ ps -A -o user,group,cmd | grep -ie vdr
vdradmi+ vdradmi+ vdradmind
pi   pi   grep --color=auto -ie vdr
vdr  vdr  /usr/bin/vdr

$ groups vdr
vdr : vdr video

I'm trying now with vdr-plugin-live : Same unsuccess result.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




You need to select correct frontend like this:

#!/bin/bash

var=$(dvb-fe-tool -a0 -f1 | grep 'Device' | awk '{print $3}')

echo 'A0 Second frontend is ' $var

if [ $var == 'MN88473' ]; then

echo 'A0 frontend is ' $var

mv /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend2
mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0
mv /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/frontend1

fi

var=$(dvb-fe-tool -a0 -f0 | grep 'Device' | awk '{print $3}')

if [ $var == 'MN88473' ]; then

dvb-fe-tool -a0 -f0 -d DVBT2

dvb-fe-tool -a0 -f0 -g |grep DELIVERY

fi


Second frontend with this adapter can handle DVBC/ANNEX_A too.

Vdr should know both frontends and use correct one and setup delivery 
system either by setup parameter or trying which one is working and 
prefer DVBT2. With satelite channnels it knows when to use S2. W_scan 
can handle this too.


Other version of this device can have CXD2837ER as second frontend name.

Timo

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


More info:

http://blog.palosaari.fi/2014/09/naked-hardware-18-astrometa-amdvb-t2-v2.html

Timo

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Timo Helkiö]

Helmut Binder kirjoitti 29.11.2020 klo 15.11:

On Sat, 28 Nov 2020 17:44:32 +0100
Narcis Garcia  wrote:


_
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:

On 28.11.20 17:30, Narcis Garcia wrote:

Hello,

I've installed vdr from Raspbian packages, to use it with Kodi.
I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
channels are found.

But I try to watch some channel and I get no data.


Does the user id under which you run VDR have access to the
DVB devices?

Klaus



$ ls -la /dev/dvb/adapter0/
total 0
drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0



This is a multi-frontend device. You need VDR-2.4.1 or newer - or at least this 
patch from here:
https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966

Helmut


$ ps -A -o user,group,cmd | grep -ie vdr
vdradmi+ vdradmi+ vdradmind
pi   pi   grep --color=auto -ie vdr
vdr  vdr  /usr/bin/vdr

$ groups vdr
vdr : vdr video

I'm trying now with vdr-plugin-live : Same unsuccess result.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




You need to select correct frontend like this:

#!/bin/bash

var=$(dvb-fe-tool -a0 -f1 | grep 'Device' | awk '{print $3}')

echo 'A0 Second frontend is ' $var

if [ $var == 'MN88473' ]; then

echo 'A0 frontend is ' $var

mv /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend2
mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0
mv /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/frontend1

fi

var=$(dvb-fe-tool -a0 -f0 | grep 'Device' | awk '{print $3}')

if [ $var == 'MN88473' ]; then

dvb-fe-tool -a0 -f0 -d DVBT2

dvb-fe-tool -a0 -f0 -g |grep DELIVERY

fi


Second frontend with this adapter can handle DVBC/ANNEX_A too.

Vdr should know both frontends and use correct one and setup delivery 
system either by setup parameter or trying which one is working and 
prefer DVBT2. With satelite channnels it knows when to use S2. W_scan 
can handle this too.


Other version of this device can have CXD2837ER as second frontend name.

Timo

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Helmut Binder]

On Sat, 28 Nov 2020 17:44:32 +0100
Narcis Garcia  wrote:

> _
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
> > On 28.11.20 17:30, Narcis Garcia wrote:
> >> Hello,
> >>
> >> I've installed vdr from Raspbian packages, to use it with Kodi.
> >> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
> >> channels are found.
> >>
> >> But I try to watch some channel and I get no data.
> > 
> > Does the user id under which you run VDR have access to the
> > DVB devices?
> > 
> > Klaus
> > 
> 
> $ ls -la /dev/dvb/adapter0/
> total 0
> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
> 

This is a multi-frontend device. You need VDR-2.4.1 or newer - or at least this 
patch from here:
https://www.vdr-portal.de/forum/index.php?thread/132190-patch-f%C3%BCr-multi-frontend-devices/=1308966#post1308966

Helmut

> $ ps -A -o user,group,cmd | grep -ie vdr
> vdradmi+ vdradmi+ vdradmind
> pi   pi   grep --color=auto -ie vdr
> vdr  vdr  /usr/bin/vdr
> 
> $ groups vdr
> vdr : vdr video
> 
> I'm trying now with vdr-plugin-live : Same unsuccess result.
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 28/11/20 a les 23:01, Klaus Schmidinger ha escrit:
> On 28.11.20 17:55, Narcis Garcia wrote:
>> ...
>> de nov. 28 17:33:12 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
>> lock on channel 23 (Telecinco), tp 586
>> de nov. 28 17:33:13 raspberrypi vdr[30508]: [30514] frontend 0/0
>> regained lock on channel 23 (Telecinco), tp 586
> 
> Maybe a bad cable/connector?
> 
> Klaus
> 

Should not, because Kaffeine app lets watch TV (with VDR stopped).
Narcís.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Klaus Schmidinger]

On 29.11.20 11:33, Narcis Garcia wrote:

...
de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] ERROR (dvbdevice.c,1650): 
/dev/dvb/adapter0/frontend1: El dispositiu o recurs es troba ocupat


If this error message was given in English I might be able to interpret it.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Klaus Schmidinger]

On 28.11.20 17:55, Narcis Garcia wrote:

...
de nov. 28 17:33:12 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:13 raspberrypi vdr[30508]: [30514] frontend 0/0
regained lock on channel 23 (Telecinco), tp 586


Maybe a bad cable/connector?

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

El 28/11/20 a les 17:44, Narcis Garcia ha escrit:
> _
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
>> On 28.11.20 17:30, Narcis Garcia wrote:
>>> Hello,
>>>
>>> I've installed vdr from Raspbian packages, to use it with Kodi.
>>> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
>>> channels are found.
>>>
>>> But I try to watch some channel and I get no data.
>> Does the user id under which you run VDR have access to the
>> DVB devices?
>>
>> Klaus
>>
> $ ls -la /dev/dvb/adapter0/
> total 0
> drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
> drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
> crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
> crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
> crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
> crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
> crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0
>
> $ ps -A -o user,group,cmd | grep -ie vdr
> vdradmi+ vdradmi+ vdradmind
> pi   pi   grep --color=auto -ie vdr
> vdr  vdr  /usr/bin/vdr
>
> $ groups vdr
> vdr : vdr video
>
> I'm trying now with vdr-plugin-live : Same unsuccess result.
>
WHEN I JUST START SERVICE:

$ sudo systemctl status vdr
● vdr.service - Video Disk Recorder
   Loaded: loaded (/lib/systemd/system/vdr.service; enabled; vendor
preset: enabled)
   Active: active (running) since Sat 2020-11-28 17:31:10 CET; 13s ago
  Process: 30488 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh
commands (code=exited, status=0/SUCCESS)
  Process: 30498 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh
reccmds (code=exited, status=0/SUCCESS)
 Main PID: 30508 (vdr)
   Status: "Ready"
    Tasks: 9 (limit: 3748)
   CGroup: /system.slice/vdr.service
   └─30508 /usr/bin/vdr

de nov. 28 17:31:10 raspberrypi vdr[30508]: [30508] ERROR: no OSD
provider available - using dummy OSD!
de nov. 28 17:31:20 raspberrypi vdr[30508]: [30508] loading
/var/cache/vdr/cam.data
de nov. 28 17:31:20 raspberrypi vdr[30508]: [30508] switching to channel
1 T-0-17-155 (mega)
de nov. 28 17:31:20 raspberrypi vdr[30508]: [30508] setting watchdog
timer to 60 seconds
de nov. 28 17:31:20 raspberrypi vdr[30508]: [32663] SVDRP server handler
thread started (pid=30508, tid=32663, prio=low)
de nov. 28 17:31:20 raspberrypi vdr[30508]: [32663] SVDRP raspberrypi
opening port 6419/tcp
de nov. 28 17:31:20 raspberrypi vdr[30508]: [32663] SVDRP raspberrypi
listening on port 6419/tcp
de nov. 28 17:31:20 raspberrypi vdr[30508]: [30508] OSD size changed to
720x480 @ 1
de nov. 28 17:31:20 raspberrypi vdr[30508]: [30508] ERROR: no OSD
provider available - using dummy OSD!
de nov. 28 17:31:21 raspberrypi vdr[30508]: [30508] max. latency time 1
seconds

AFTER A MINUTE OF RUNNING SERVICE (I was trying to switch TV channel
from a client):

$ sudo systemctl status vdr
● vdr.service - Video Disk Recorder
   Loaded: loaded (/lib/systemd/system/vdr.service; enabled; vendor
preset: enabled)
   Active: active (running) since Sat 2020-11-28 17:31:10 CET; 2min 21s ago
  Process: 30488 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh
commands (code=exited, status=0/SUCCESS)
  Process: 30498 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh
reccmds (code=exited, status=0/SUCCESS)
 Main PID: 30508 (vdr)
   Status: "Ready"
    Tasks: 9 (limit: 3748)
   CGroup: /system.slice/vdr.service
   └─30508 /usr/bin/vdr

de nov. 28 17:33:12 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:13 raspberrypi vdr[30508]: [30514] frontend 0/0
regained lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:16 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:18 raspberrypi vdr[30508]: [30514] frontend 0/0
regained lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:21 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:21 raspberrypi vdr[30508]: [30514] frontend 0/0
regained lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:24 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:25 raspberrypi vdr[30508]: [30514] frontend 0/0
regained lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:28 raspberrypi vdr[30508]: [30514] frontend 0/0 lost
lock on channel 23 (Telecinco), tp 586
de nov. 28 17:33:28 raspberrypi vdr[30508]: [30514] frontend 0/0
regained lock on channel 23 (Telecinco), tp 586



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Narcis Garcia]

_
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 28/11/20 a les 17:33, Klaus Schmidinger ha escrit:
> On 28.11.20 17:30, Narcis Garcia wrote:
>> Hello,
>>
>> I've installed vdr from Raspbian packages, to use it with Kodi.
>> I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
>> channels are found.
>>
>> But I try to watch some channel and I get no data.
> 
> Does the user id under which you run VDR have access to the
> DVB devices?
> 
> Klaus
> 

$ ls -la /dev/dvb/adapter0/
total 0
drwxr-xr-x  2 root root  140 de nov.  28 15:57 .
drwxr-xr-x  3 root root   60 de nov.  28 15:57 ..
crw-rw+ 1 root video 212,  4 de nov.  28 15:57 demux0
crw-rw+ 1 root video 212,  5 de nov.  28 15:57 dvr0
crw-rw+ 1 root video 212,  3 de nov.  28 15:57 frontend0
crw-rw+ 1 root video 212, 19 de nov.  28 15:57 frontend1
crw-rw+ 1 root video 212,  7 de nov.  28 15:57 net0

$ ps -A -o user,group,cmd | grep -ie vdr
vdradmi+ vdradmi+ vdradmind
pi   pi   grep --color=auto -ie vdr
vdr  vdr  /usr/bin/vdr

$ groups vdr
vdr : vdr video

I'm trying now with vdr-plugin-live : Same unsuccess result.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr not working in Raspbian 10

[Klaus Schmidinger]

On 28.11.20 17:30, Narcis Garcia wrote:

Hello,

I've installed vdr from Raspbian packages, to use it with Kodi.
I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV
channels are found.

But I try to watch some channel and I get no data.


Does the user id under which you run VDR have access to the
DVB devices?

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR do not show HD channels.

[Klaus Schmidinger]

On 22.11.20 13:42, Richard F wrote:

...
I'll see if I can rebuild with latest.  I already can't rebuild a couple of 
plugins on SuSe 15.2/gcc 7 (bug logged for smartvweb a long time back), I'm 
concerned more things might break, which is why I'm still on 2.20. But I'll try.


You don't need any plugins (except for output) to test this.

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR do not show HD channels.

[Richard F]

On 21/11/2020 4:24 pm, Klaus Schmidinger wrote:

On 21.11.20 17:11, Richard F wrote:
Klaus  - thanks for your reply.   2 problems - the first is my own - 
I don't like all the rubbish shopping channels filling up my channel 
list and I sort it manually to keep the channels in a sensible order 
instead of the random order the broadcasters have ended up with - so 
I have the 'updatechannels' setting at 3 instead of 5.


Problem 2 is that VDR doesn't complete HD tuning - at least in first 
30 mins or so, example here - I deleted BBC1HD & BBC2HD, set the 
update value to 5, restarted and let it retune. It added both back, 
but BBC1HD is saved like this after about 30 mins 
(incomplete/nonworking):


BBC ONE 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:0:0:0:0:17540:9018:16516:0


The right tuning values are:

BBC ONE 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:6601=27:6602=eng@17,6606=eng@17:0;6605=eng:0:17540:9018:16516:0


Bit it did get BBC2HD right immediately - on the same multiplex.

BBC TWO 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16516:0


The transponder data and the PIDs are broadcast in separate lists.
Maybe the PID list is parsed before the transponder list, and thus the
PIDs are missed for BBC ONE HD.

IIRC there were some changes in list parsing after version 2.2 (which 
I understand is
the version you have in use). Can you please try the latest version 
from git.tvdr.de,

to see whether this problem still persists?

Klaus

I'll see if I can rebuild with latest.  I already can't rebuild a couple 
of plugins on SuSe 15.2/gcc 7 (bug logged for smartvweb a long time 
back), I'm concerned more things might break, which is why I'm still on 
2.20. But I'll try.


Richard


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR do not show HD channels.

[Klaus Schmidinger]

On 21.11.20 17:11, Richard F wrote:
Klaus  - thanks for your reply.   2 problems - the first is my own - I don't like all the rubbish shopping channels filling up my channel list and I sort it manually to keep the channels in a sensible order instead of the random order the broadcasters have ended up with - so I have the 
'updatechannels' setting at 3 instead of 5.


Problem 2 is that VDR doesn't complete HD tuning - at least in first 30 mins or so, 
example here - I deleted BBC1HD & BBC2HD, set the update value to 5, restarted 
and let it retune. It added both back, but BBC1HD is saved like this after about 30 
mins (incomplete/nonworking):

BBC ONE HD:546000:G32M256P0Q16435S1T8X1:T:27500:0:0:0:0:17540:9018:16516:0

The right tuning values are:

BBC ONE 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:6601=27:6602=eng@17,6606=eng@17:0;6605=eng:0:17540:9018:16516:0

Bit it did get BBC2HD right immediately - on the same multiplex.

BBC TWO 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16516:0


The transponder data and the PIDs are broadcast in separate lists.
Maybe the PID list is parsed before the transponder list, and thus the
PIDs are missed for BBC ONE HD.

IIRC there were some changes in list parsing after version 2.2 (which I 
understand is
the version you have in use). Can you please try the latest version from 
git.tvdr.de,
to see whether this problem still persists?

Klaus


After maybe an hour or so, it seems to update and get it right, so it may just be that I'm not waiting long enough for the HD channels to re-tune when doing this way, or maybe something to do with the first channel?  Nowadays I let the SD channels tune themselves the same way, and they are OK in a 
minute or 2.  My normal process is to set updatechannels to 5 to capture new stuff occasionally, then manually re-sort the new channels added, and reset to 3.


Appreciate your views.


On 20/11/2020 1:00 pm, Klaus Schmidinger wrote:

I have several DVB-T2 channels in my list, for instance:

Das Erste 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4113=36:4114=deu@17,4115=mis@17:4116:0:769:8468:12291:0
arte 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:4134:0:770:8468:12291:0
phoenix 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4145=36:4146=deu@17,4147=mul@17:4148:0:771:8468:12291:0
tagesschau24 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4161=36:4162=deu@17:4163:0:772:8468:12291:0
ONE 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4177=36:4178=deu@17,4179=mis@17:4180:0:773:8468:12291:0

If I delete "arte HD" it gets re-added automatically (after I switch to that 
transponder again):

Nov 20 13:55:33 vdr3 vdr: [26237] creating new channel 'arte HD,;BR' on T 
transponder 554 with id 8468-12291-770-0
Nov 20 13:55:34 vdr3 vdr: [26237] changing pids of channel 2096 (arte HD) from 
0+0=0:0:0:0 to 
4129+4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:0:4134

Where exactly is the problem?

Klaus


On 19.11.20 13:34, Richard F wrote:

I'm using DVB-T2 with a PC-TV 290E USB nanostick in UK. I'm also still on V2.20.

My notes on tuning confirm that "... this (setting VDR to find new transponders) 
doesn't seem to be able to config HD channels - can check TS-ID, ON-ID Srv-ID with Sony 
TV"

Basically I have to hand-edit the parameters taken off a normal HD TV, as also none of the 3rd party tuning tools seem to properly tune HD for me, and I've tried many of them and many versions and methods over the years. I once thought I had it working with w_scan, but no longer, results don't 
work, though w_scan does see the channels. Would be really good to fix ! Sadly I think most or all of these 3rd party tools are now effectively unmaintained.


Richard

On 18/11/2020 9:50 pm, prelude wrote:

Hello and thx for this great VDR software.

Could someone help me at the start as I cannot get dvb-t2 channels visible in 
VDR?
If I add HD channels manually in channels.conf then VDR mark those as OBSOLETE. Yesterday I even clean my channels.conf totally and just left one channel on it and put in setup "add new transponders". In the morning all DVB-T channels were in channels.conf file but not any DVB-T2. tvheadend 
works fine also in HD channels but i just like so much more VDR user experience that i don't want to change it.





___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR do not show HD channels.

[Richard F]

Klaus  - thanks for your reply.   2 problems - the first is my own - I 
don't like all the rubbish shopping channels filling up my channel list 
and I sort it manually to keep the channels in a sensible order instead 
of the random order the broadcasters have ended up with - so I have the 
'updatechannels' setting at 3 instead of 5.


Problem 2 is that VDR doesn't complete HD tuning - at least in first 30 
mins or so, example here - I deleted BBC1HD & BBC2HD, set the update 
value to 5, restarted and let it retune. It added both back, but BBC1HD 
is saved like this after about 30 mins (incomplete/nonworking):


BBC ONE HD:546000:G32M256P0Q16435S1T8X1:T:27500:0:0:0:0:17540:9018:16516:0

The right tuning values are:

BBC ONE 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:6601=27:6602=eng@17,6606=eng@17:0;6605=eng:0:17540:9018:16516:0


Bit it did get BBC2HD right immediately - on the same multiplex.

BBC TWO 
HD:546000:G32M256P0Q16435S1T8X1:T:27500:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16516:0


After maybe an hour or so, it seems to update and get it right, so it 
may just be that I'm not waiting long enough for the HD channels to 
re-tune when doing this way, or maybe something to do with the first 
channel?  Nowadays I let the SD channels tune themselves the same way, 
and they are OK in a minute or 2.  My normal process is to set 
updatechannels to 5 to capture new stuff occasionally, then manually 
re-sort the new channels added, and reset to 3.


Appreciate your views.


On 20/11/2020 1:00 pm, Klaus Schmidinger wrote:

I have several DVB-T2 channels in my list, for instance:

Das Erste 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4113=36:4114=deu@17,4115=mis@17:4116:0:769:8468:12291:0
arte 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:4134:0:770:8468:12291:0
phoenix 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4145=36:4146=deu@17,4147=mul@17:4148:0:771:8468:12291:0
tagesschau24 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4161=36:4162=deu@17:4163:0:772:8468:12291:0
ONE 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4177=36:4178=deu@17,4179=mis@17:4180:0:773:8468:12291:0


If I delete "arte HD" it gets re-added automatically (after I switch 
to that transponder again):


Nov 20 13:55:33 vdr3 vdr: [26237] creating new channel 'arte HD,;BR' 
on T transponder 554 with id 8468-12291-770-0
Nov 20 13:55:34 vdr3 vdr: [26237] changing pids of channel 2096 (arte 
HD) from 0+0=0:0:0:0 to 
4129+4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:0:4134


Where exactly is the problem?

Klaus


On 19.11.20 13:34, Richard F wrote:
I'm using DVB-T2 with a PC-TV 290E USB nanostick in UK. I'm also 
still on V2.20.


My notes on tuning confirm that "... this (setting VDR to find new 
transponders) doesn't seem to be able to config HD channels - can 
check TS-ID, ON-ID Srv-ID with Sony TV"


Basically I have to hand-edit the parameters taken off a normal HD 
TV, as also none of the 3rd party tuning tools seem to properly tune 
HD for me, and I've tried many of them and many versions and methods 
over the years. I once thought I had it working with w_scan, but no 
longer, results don't work, though w_scan does see the channels.   
Would be really good to fix ! Sadly I think most or all of these 3rd 
party tools are now effectively unmaintained.


Richard

On 18/11/2020 9:50 pm, prelude wrote:

Hello and thx for this great VDR software.

Could someone help me at the start as I cannot get dvb-t2 channels 
visible in VDR?
If I add HD channels manually in channels.conf then VDR mark those 
as OBSOLETE. Yesterday I even clean my channels.conf totally and 
just left one channel on it and put in setup "add new transponders". 
In the morning all DVB-T channels were in channels.conf file but not 
any DVB-T2. tvheadend works fine also in HD channels but i just like 
so much more VDR user experience that i don't want to change it.





___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR do not show HD channels.

[Klaus Schmidinger]

I have several DVB-T2 channels in my list, for instance:

Das Erste 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4113=36:4114=deu@17,4115=mis@17:4116:0:769:8468:12291:0
arte 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:4134:0:770:8468:12291:0
phoenix 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4145=36:4146=deu@17,4147=mul@17:4148:0:771:8468:12291:0
tagesschau24 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4161=36:4162=deu@17:4163:0:772:8468:12291:0
ONE 
HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4177=36:4178=deu@17,4179=mis@17:4180:0:773:8468:12291:0

If I delete "arte HD" it gets re-added automatically (after I switch to that 
transponder again):

Nov 20 13:55:33 vdr3 vdr: [26237] creating new channel 'arte HD,;BR' on T 
transponder 554 with id 8468-12291-770-0
Nov 20 13:55:34 vdr3 vdr: [26237] changing pids of channel 2096 (arte HD) from 
0+0=0:0:0:0 to 
4129+4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:0:4134

Where exactly is the problem?

Klaus


On 19.11.20 13:34, Richard F wrote:

I'm using DVB-T2 with a PC-TV 290E USB nanostick in UK. I'm also still on V2.20.

My notes on tuning confirm that "... this (setting VDR to find new transponders) 
doesn't seem to be able to config HD channels - can check TS-ID, ON-ID Srv-ID with Sony 
TV"

Basically I have to hand-edit the parameters taken off a normal HD TV, as also none of the 3rd party tuning tools seem to properly tune HD for me, and I've tried many of them and many versions and methods over the years. I once thought I had it working with w_scan, but no longer, results don't work, 
though w_scan does see the channels.   Would be really good to fix !  Sadly I think most or all of these 3rd party tools are now effectively unmaintained.


Richard

On 18/11/2020 9:50 pm, prelude wrote:

Hello and thx for this great VDR software.

Could someone help me at the start as I cannot get dvb-t2 channels visible in 
VDR?
If I add HD channels manually in channels.conf then VDR mark those as OBSOLETE. Yesterday I even clean my channels.conf totally and just left one channel on it and put in setup "add new transponders". In the morning all DVB-T channels were in channels.conf file but not any DVB-T2. tvheadend works 
fine also in HD channels but i just like so much more VDR user experience that i don't want to change it.


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR do not show HD channels.

[Richard F]

I'm using DVB-T2 with a PC-TV 290E USB nanostick in UK. I'm also still 
on V2.20.


My notes on tuning confirm that "... this (setting VDR to find new 
transponders) doesn't seem to be able to config HD channels - can check 
TS-ID, ON-ID Srv-ID with Sony TV"


Basically I have to hand-edit the parameters taken off a normal HD TV, 
as also none of the 3rd party tuning tools seem to properly tune HD for 
me, and I've tried many of them and many versions and methods over the 
years. I once thought I had it working with w_scan, but no longer, 
results don't work, though w_scan does see the channels.   Would be 
really good to fix !  Sadly I think most or all of these 3rd party tools 
are now effectively unmaintained.


Richard

On 18/11/2020 9:50 pm, prelude wrote:

Hello and thx for this great VDR software.

Could someone help me at the start as I cannot get dvb-t2 channels 
visible in VDR?
If I add HD channels manually in channels.conf then VDR mark those as 
OBSOLETE. Yesterday I even clean my channels.conf totally and just 
left one channel on it and put in setup "add new transponders". In the 
morning all DVB-T channels were in channels.conf file but not any 
DVB-T2. tvheadend works fine also in HD channels but i just like so 
much more VDR user experience that i don't want to change it.







___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR system on Raspberry pi vs these all in one systems

[VDRU VDRU]

By `read made systems` I assume you mean devices like Nvidia Shield,
Amazon Firestick, Vero, the various Amlogic-based boxes, etc. These
are basically meant to be plug-and-play so I'm not sure why you think
they'd be any more complicated than building a VDR setup. I know
several people who use them and I've never heard anyone complain about
swapping out storage. If some device does have issues with
hot-swapping usb, it's not like turning the box off, swapping the usb
storage out and then turning it back on should be a problem.

One of the first problems is waiting so long to upgrade from long
deprecated VCR recorders and VHS tapes. I would strongly recommend you
_not_ invest any more money into such ancient and dead-end technology
and instead use your resources to modernize. The cost of staying with,
maintaining, repairing, replacing VCR's and VHS will far exceed the
cost to modernize.

The next problem you have is restricting yourself to OTA content
providers that sounds like they offer limited and patchy guide data at
best. No setup will give you what isn't available. You're going to
have to find some kind of alternative for guide data, or make due.

As far as recommendations, only you know what your budget is. If you
simply can't afford a suitable plug-and-play device then your only
choice is to go with Raspberry Pi (or similar) and get your hands
dirty. The one thing I will say is a Raspberry Pi setup is going to
cost more than $35 when you factor in the additional cost of a power
supply, case, storage, cables, etc. (unless you already have all
that). $35 gets you a Raspberry Pi mainboard, it doesn't get you
everything you need to actually use it.

On Sun, Sep 27, 2020 at 4:27 PM Timothy D. Lenz  wrote:
>
> 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.
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR does not find S13E channels after upgrading (not quite solved yet)

[Harald Milz]

Hi all,

On Thu, Apr 30, 2020 at 05:46:44PM +0200, Harald Milz wrote:
> 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. 

[Background: since my upgrade from 2.2.0 to yavdr-2.4.0, VDR has been 
confused about channel to device allocation. I have 2 dual LNBs pointing to
Astra 19.2E and Hotbird 13E, respectively, attached to a 4-port Digital
Devices V 6.5 card. I also upgraded dddvb-0.9.32 to 0.9.38 from git. With the
old installation, all worked fine. Sorry for writing in German in my first
post.]

In order to bind the 13E channels to device 3, I modified the CAIDs for
the affected channels to 3 now. Device 4 should be able to receive these
channels as well, but I rarely need 2 of them at the same time, and VDR seems to
ignore 2 channels written as x,y in the CAID field anyway.

This seems to work for now, although I do not consider this a permanent fix. I
will keep looking if VDR again attempts to use device 3 or 4 for Astra
channels. 

I also suspected a broken disecq.conf although I had not changed it during the
upgrade, and replaced it by an empty file, but this confused VDR even more. 

Also, last night I was watching ZDF (with Kodi), when a recording on ARD
started, which killed the ZDF live stream and crashed VDR. :-/ That should not
happen with 2 available receivers. Turned out, VDR had attempted to use device
3 for the ARD recording, resulting in a VDSB error. m(

Very strange. It feels like a bug, but this would affect everyone with 2.4.0
using 2 sats and 4 receivers, or the yavdr-2.4.0 build would be buggy, which I
cannot imagine (why would they patch something here?). 

I think it's more plausible that there is something foul in the state of
configs, something subtle and not obvious (to me). Any further idea where to
look is appreciated! 

THX! 

-- 
Your lucky color has faded.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR findet S13E nicht mehr nach Upgrade

[Udo Richter]

On 30.04.20 17:46, Harald Milz wrote:

Nach längerem habe ich mich endlich aufgerafft,


Wenn man plötzlich Zeit hat, und never-touch-a-running-system neu
aufsetzt... woher kenn ich das? ^^


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.


Ich hab kein so kompliziertes Setup, deswegen generische Tipps: Ich würd
erst mal versuchen, die Konfiguration auf die Frontends 3 und 4
einzuschränken und ohne Doppelsetup nur testen, ob Hotbird überhaupt will.
Wenn das geht, was passiert, wenn man Astra auf 3,4 und Hotbird auf 1,2
legt? So kann man das Problem schon mal rein auf Software eingrenzen.


Gruß,

Udo

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR 2.20 skincurses build error GCC7

[Richard F]

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-requ...@linuxtv.org wrote:
> Subject:
> Re: [vdr] VDR 2.20 skincurses build error GCC7
> From:
> Klaus Schmidinger 
> Date:
> 3/06/2019, 09:36
>
> To:
> vdr@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.diff
>
>
> Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR 2.20 skincurses build error GCC7

[Klaus Schmidinger]

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.diff

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr Digest, Vol 161, Issue 4

[prelude]

VDR User kirjoitti 2018-10-31 16:07:


 Intel/VAAPI has been very smooth &
stable here. Not a single problem and no bugs that I've experienced.


As you have working system, could you also list HW what you use and 
related SW's with version inffo's? This way we can go forward with this 
question and hopefully avoid unfruitful conversations.



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr Digest, Vol 161, Issue 4

[VDR User]

> you can have a look at the nvidia gt 1030 cards. there are lowprofile and 
> fanless versions,
> but pay attention to card size.
> and you may need to install correct drivers manually.
> but, half the price then an intel nuc with luck.

If all you need is a video card, that's a decent option. If you're
looking for a whole new system, you'll easily spend more than the cost
of a NUC.

> i'm considering this myself, too, instead of this buggy intel hd grahpics... 
> (well, nvidia isn't better, i know...)

What bug(s) are you referring to? Intel/VAAPI has been very smooth &
stable here. Not a single problem and no bugs that I've experienced.
From what I can tell the people talking about buggy drivers don't
actually use Intel HD, they just seem to be repeating what someone
else said, or maybe they have a problem outside of VDR/Kodi/HTPC/media
playback.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr Digest, Vol 161, Issue 4

[Jukka Tastula]

On 31/10/2018 11:50, master.of.brainless.thi...@gmx.net wrote:
> you can have a look at the nvidia gt 1030 cards. there are lowprofile
> and fanless versions,
> but pay attention to card size. and you may need to install correct
> drivers manually. but, half the price then an intel nuc with luck. i'm
> considering this myself, too, instead of this buggy intel hd
> grahpics... (well, nvidia isn't better, i know...) afaik, the gt 1030
> is capable of playing 4k hdr h265 encoded videos, what is presumably
> what you need. i've read about netfix 4k support, too. 

Also one thing to look out for is that the 1030 actually comes in GDDR5
and DDR4 variants. They are priced very similarly, but performance of
DDR4 is absolute garbage compared to GDDR5!

I doubt this will have an effect when it comes to video decoding
capability, but paying about the same for half the performance doesn't
seem like a good idea to me.




___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr Digest, Vol 161, Issue 4

[master.of.brainless.things]

Am Tue, 30 Oct 2018 12:00:01 +
schrieb vdr-requ...@linuxtv.org:

> > I plan to upgrade my VDR box, with these two important features :
> > - reading mkv files => I am using xineliboutput and vdpau.  
> 
> MKV is just a container for data streams and support is wide-spread.
> Any half-decent player supports mkv. It's also unrelated to
> xineliboutput and VDPAU so I assume what you actually mean by mkv is
> being able to play back HD or greater content using VDPAU for decoding
> and xineliboutput to get the decoded frames to your tv. VDPAU is EOL.
> Nvidia currently has NVDEC but I can't speak to how well it's
> supported since I dumped VDPAU for VAAPI a while back.
> 
> > - receiving 4K channels => for HD, I am using old PCI/PCIE motherboard + 
> > TBS6928 (with CI).
> >
> > Could you share best hardware cpu/video/card,motherboard/..., & best 
> > plugin/driver/... you advice at the moment?  
> 
> When I switched from VDPAU to VAAPI I retired my old hardware and just
> spent about $120 on an Intel NUC, and couldn't be happier. I'll never
> bother with video cards again for htpc/media playing boxes. And also
> non-usb tuners. Low power/low space is my theme now so my days of
> building pc's for this purpose are over. You might want to look at
> other options unless you actually want a pc tower.

you can have a look at the nvidia gt 1030 cards. there are lowprofile and 
fanless versions,
but pay attention to card size.
and you may need to install correct drivers manually.
but, half the price then an intel nuc with luck.

i'm considering this myself, too, instead of this buggy intel hd grahpics... 
(well, nvidia isn't better, i know...)

afaik, the gt 1030 is capable of playing 4k hdr h265 encoded videos, what is 
presumably what you need.
i've read about netfix 4k support, too.

-- 
/*
 *  printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",...);
 *  linux-2.6.6/drivers/net/sundance.c
 */


pgp_OkI3BWEgI.pgp
Description: Digitale Signatur von OpenPGP
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR ISDB-T support

[Sergio Daniel Gomez]

Sorry for my reply of a very old message. My appology.

El 13/09/2018 a las 22:31, Sergio Daniel Gomez escribió:


Hi Thomas.

Do you know TBS ISDB-T cards?

Quad tuner 
https://www.tbsdtv.com/products/tbs6814-isdb-t-quad-tuner-pcie-card.html


and multistandard octa tuner 
https://www.tbsdtv.com/products/tbs6209-dvb-t2-c2-tc-isdbt-octatv-tuner.html


Kind regrads

Sergio

El 04/08/2015 a las 7:06, Thomas Netousek escribió:


Hi Christian,

thanks for sharing your experience !

Do you know of any good ISDB-T internal cards ?
I looked around, but for DVB-T I find many dual receiver cards, for 
ISDB-T it looks like there are "only" single-receiver USB sticks ?



Kind regards from Vienna, Austria

Thomas

On 08/04/15 08:12, Christian Rodriguez wrote:
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/dadbca57c2dc55c1c53b4fa8f68b56728ab72ddd#diff-8fe0655a5feb333a97bf3a2a8b451546R1294

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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




Logotipo de AVG 

Este correo electrónico ha sido comprobado en busca de virus con el 
software antivirus AVG.

www.avg.com 


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR ISDB-T support

[Sergio Daniel Gomez]

Hi Thomas.

Do you know TBS ISDB-T cards?

Quad tuner 
https://www.tbsdtv.com/products/tbs6814-isdb-t-quad-tuner-pcie-card.html


and multistandard octa tuner 
https://www.tbsdtv.com/products/tbs6209-dvb-t2-c2-tc-isdbt-octatv-tuner.html


Kind regrads

Sergio

El 04/08/2015 a las 7:06, Thomas Netousek escribió:


Hi Christian,

thanks for sharing your experience !

Do you know of any good ISDB-T internal cards ?
I looked around, but for DVB-T I find many dual receiver cards, for 
ISDB-T it looks like there are "only" single-receiver USB sticks ?



Kind regards from Vienna, Austria

Thomas

On 08/04/15 08:12, Christian Rodriguez wrote:
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/dadbca57c2dc55c1c53b4fa8f68b56728ab72ddd#diff-8fe0655a5feb333a97bf3a2a8b451546R1294

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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Montag, den 02.04.2018, 18:40 +0200 schrieb Klaus Schmidinger:
> On 02.04.2018 14:20, Oliver Endriss wrote:
> > Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger:
> >> On 01.04.2018 19:01, Oliver Endriss wrote:
> >> > ...
> >> >> >> >> Does it make a difference whether the progress display is active 
> >> >> >> >> or not
> >> >> >> >> when you set the mark?
> >> >> > 
> >> >> > If the progress bar is off, and you set a mark, progress bar and
> >> >> > mark show up immediately. -> No problem.
> >> >> 
> >> >> ...
> >> >> > Could it be that this action is triggered _before_ the mark has been
> >> >> > written to the OSD buffer? In this case, the OSD would be displayed
> >> >> > without the mark, and the mark would be displayed during the next
> >> >> > cycle, i.e. one second later.
> >> >> 
> >> >> I doubt that.
> >> 
> >> Well, meanwhile I think you were right here.
> >> In cReplayControl::MarkToggle() there is
> >> 
> >>lastCurrent = -1; // triggers redisplay
> >> 
> >> which it used to do until the switch to GetFrameNumber() ;-).
> >> 
> >> Now this has no immediate effect any more, and that may explain
> >> the sluggishness you observe.
> >> 
> >> Please try this:
> >> 
> >> --- menu.c  2018/03/24 11:43:40 4.70
> >> +++ menu.c  2018/04/02 10:07:05
> >> @@ -5728,7 +5728,7 @@
> >>   bool cReplayControl::ShowProgress(bool Initial)
> >>   {
> >> int Current, Total;
> >> -  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) 
> >> {
> >> +  if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - 
> >> lastProgressUpdate >= 1) {
> >>if (GetFrameNumber(Current, Total) && Total > 0) {
> >>   if (!visible) {
> >>  displayReplay = Skins.Current()->DisplayReplay(modeOnly);
> >> 
> >> > I am pretty sure that something is wrong.
> >> > With the following (ugly) patch, the problem is gone:
> >> > ...
> >> > All it does is executing the code in 'if (Initial...)' one more time,
> >> > after lastProgressUpdate has been set to 0.
> >> 
> >> Thanks for pointing this out. This triggered my idea with lastCurrent 
> >> above.
> > 
> > Thanks, your patch fixed the issue.
> 
> Taking a step back and considering that GetFrameNumber() was supposed to
> be a drop-in replacement for GetIndex(), just returning the exact number
> of the currently replayed frame and not just the index into the 'index'
> file (which, apart from I-frames, is typically different) I revoked the
> whole change and simply replaced GetIndex() with GetFrameNumber(). That
> resulted in the sluggish progress display on the Raspberry Pi I reported
> earlier. I then found that this was caused by the extra Flush() calls in
> cReplayControl::ShowProgress(). So I removed them and now everything runs
> smoothly on the RasPi and also on softhddevice.
> So please try the attached patch instead of the previous one, and especially
> check whether it still works on the dvbsddevice. This should hopefully also
> fix the "jumping progress display".

Works fine with HD/SD/radio recordings. Tested with dvbhddevice
and dvbsddevice. Both problems are fixed. Thank you.

> There is, apparently, still a problem on the RasPi, where once you set
> a mark, a subsequent "play" doesn't take effect until a couple of seconds
> later. However, since this doesn't occur with softhddevice, I assume this
> is a RasPi specific problem. I'll discuss this with Thomas separately.

This does not occur with the FF cards.

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 02.04.2018 14:22, Torgeir Veimo wrote:

Do you have any plans for more integrated means of running a client server 
setup like the streamdev setup? I like the raspberry pi since it's low power, 
and does hdmi-cec, but without sata I'm concerned with disk bandwidth with 
multiple recordings.


This already works very good with remote timers in VDR 2.3.9 (that's
the setup I currently use). For replaying recordings I just mount the
server's video directory on the RasPi. There's more to come after
version 2.4.0 ;-).

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 02.04.2018 14:20, Oliver Endriss wrote:

Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger:

On 01.04.2018 19:01, Oliver Endriss wrote:
> ...
>> >> >> Does it make a difference whether the progress display is active or not
>> >> >> when you set the mark?
>> > 
>> > If the progress bar is off, and you set a mark, progress bar and

>> > mark show up immediately. -> No problem.
>> 
>> ...

>> > Could it be that this action is triggered _before_ the mark has been
>> > written to the OSD buffer? In this case, the OSD would be displayed
>> > without the mark, and the mark would be displayed during the next
>> > cycle, i.e. one second later.
>> 
>> I doubt that.


Well, meanwhile I think you were right here.
In cReplayControl::MarkToggle() there is

   lastCurrent = -1; // triggers redisplay

which it used to do until the switch to GetFrameNumber() ;-).

Now this has no immediate effect any more, and that may explain
the sluggishness you observe.

Please try this:

--- menu.c  2018/03/24 11:43:40 4.70
+++ menu.c  2018/04/02 10:07:05
@@ -5728,7 +5728,7 @@
  bool cReplayControl::ShowProgress(bool Initial)
  {
int Current, Total;
-  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+  if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - 
lastProgressUpdate >= 1) {
   if (GetFrameNumber(Current, Total) && Total > 0) {
  if (!visible) {
 displayReplay = Skins.Current()->DisplayReplay(modeOnly);

> I am pretty sure that something is wrong.
> With the following (ugly) patch, the problem is gone:
> ...
> All it does is executing the code in 'if (Initial...)' one more time,
> after lastProgressUpdate has been set to 0.

Thanks for pointing this out. This triggered my idea with lastCurrent above.


Thanks, your patch fixed the issue.


Taking a step back and considering that GetFrameNumber() was supposed to
be a drop-in replacement for GetIndex(), just returning the exact number
of the currently replayed frame and not just the index into the 'index'
file (which, apart from I-frames, is typically different) I revoked the
whole change and simply replaced GetIndex() with GetFrameNumber(). That
resulted in the sluggish progress display on the Raspberry Pi I reported
earlier. I then found that this was caused by the extra Flush() calls in
cReplayControl::ShowProgress(). So I removed them and now everything runs
smoothly on the RasPi and also on softhddevice.
So please try the attached patch instead of the previous one, and especially
check whether it still works on the dvbsddevice. This should hopefully also
fix the "jumping progress display".

There is, apparently, still a problem on the RasPi, where once you set
a mark, a subsequent "play" doesn't take effect until a couple of seconds
later. However, since this doesn't occur with softhddevice, I assume this
is a RasPi specific problem. I'll discuss this with Thomas separately.

Klaus
--- menu.h	2018/02/01 15:35:48	4.6
+++ menu.h	2018/04/02 13:41:49
@@ -300,7 +300,6 @@
   bool lastPlay, lastForward;
   int lastSpeed;
   time_t timeoutShow;
-  time_t lastProgressUpdate;
   bool timeSearchActive, timeSearchHide;
   int timeSearchTime, timeSearchPos;
   void TimeSearchDisplay(void);
--- menu.c	2018/03/24 11:43:40	4.70
+++ menu.c	2018/04/02 13:41:39
@@ -5564,7 +5564,6 @@
   lastPlay = lastForward = false;
   lastSpeed = -2; // an invalid value
   timeoutShow = 0;
-  lastProgressUpdate = 0;
   timeSearchActive = false;
   cRecording Recording(fileName);
   cStatus::MsgReplaying(this, Recording.Name(), Recording.FileName(), true);
@@ -5728,43 +5727,36 @@
 bool cReplayControl::ShowProgress(bool Initial)
 {
   int Current, Total;
-  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
- if (GetFrameNumber(Current, Total) && Total > 0) {
-if (!visible) {
-   displayReplay = Skins.Current()->DisplayReplay(modeOnly);
-   displayReplay->SetMarks();
-   SetNeedsFastResponse(true);
-   visible = true;
-   }
-if (Initial) {
-   if (*fileName) {
-  LOCK_RECORDINGS_READ;
-  if (const cRecording *Recording = Recordings->GetByName(fileName))
- displayReplay->SetRecording(Recording);
-  }
-   lastCurrent = lastTotal = -1;
+  if (GetFrameNumber(Current, Total) && Total > 0) {
+ if (!visible) {
+displayReplay = Skins.Current()->DisplayReplay(modeOnly);
+displayReplay->SetMarks();
+SetNeedsFastResponse(true);
+visible = true;
+}
+ if (Initial) {
+if (*fileName) {
+   LOCK_RECORDINGS_READ;
+   if (const cRecording *Recording = Recordings->GetByName(fileName))
+  displayReplay->SetRecording(Recording);
}
-if (Current != lastCurrent || Total != lastTotal) {
-   time();
-   if (Setup.ShowRemainingTime || Total != lastTotal) {
-  int 

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Torgeir Veimo]

Do you have any plans for more integrated means of running a client server
setup like the streamdev setup? I like the raspberry pi since it's low
power, and does hdmi-cec, but without sata I'm concerned with disk
bandwidth with multiple recordings.

On 2 April 2018 at 21:27, Klaus Schmidinger 
wrote:

> On 02.04.2018 12:35, Torgeir Veimo wrote:
>
>> Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:
>>
>> At the time this was done, I was still using the TT S2-6400 as output
>>> device.
>>>
>>
>> Jut curious, what are you using now? A raspberry pi?
>>
>
> Currently a Raspberry Pi, but I'm planning to use my J3455M board's
> graphics with softhddevice (or vaapidevice).
>
> Klaus
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



-- 
-Tor
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger:
> On 01.04.2018 19:01, Oliver Endriss wrote:
> > ...
> >> >> >> Does it make a difference whether the progress display is active or 
> >> >> >> not
> >> >> >> when you set the mark?
> >> > 
> >> > If the progress bar is off, and you set a mark, progress bar and
> >> > mark show up immediately. -> No problem.
> >> 
> >> ...
> >> > Could it be that this action is triggered _before_ the mark has been
> >> > written to the OSD buffer? In this case, the OSD would be displayed
> >> > without the mark, and the mark would be displayed during the next
> >> > cycle, i.e. one second later.
> >> 
> >> I doubt that.
> 
> Well, meanwhile I think you were right here.
> In cReplayControl::MarkToggle() there is
> 
>lastCurrent = -1; // triggers redisplay
> 
> which it used to do until the switch to GetFrameNumber() ;-).
> 
> Now this has no immediate effect any more, and that may explain
> the sluggishness you observe.
> 
> Please try this:
> 
> --- menu.c  2018/03/24 11:43:40 4.70
> +++ menu.c  2018/04/02 10:07:05
> @@ -5728,7 +5728,7 @@
>   bool cReplayControl::ShowProgress(bool Initial)
>   {
> int Current, Total;
> -  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
> +  if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - 
> lastProgressUpdate >= 1) {
>if (GetFrameNumber(Current, Total) && Total > 0) {
>   if (!visible) {
>  displayReplay = Skins.Current()->DisplayReplay(modeOnly);
> 
> > I am pretty sure that something is wrong.
> > With the following (ugly) patch, the problem is gone:
> > ...
> > All it does is executing the code in 'if (Initial...)' one more time,
> > after lastProgressUpdate has been set to 0.
> 
> Thanks for pointing this out. This triggered my idea with lastCurrent above.

Thanks, your patch fixed the issue.

> > Of course, it does not affect the 'jumping' progress bar. See below.
> > ...
> >> > Btw, with a short recording, you can see that the progress bar is
> >> > jumping in one second steps...
> >> 
> >> That's pretty much the distance between the I-frames, and thus the steps in
> >> which VDR updates the progress bar.
> > 
> > I don't care about I-frames. I use the cutter to produce small audio
> > or video clips. The current behavior of the progress bar is annoying,
> > when I play these clips. Anyway, I can easily revert the code to get
> > the old behavior.
> 
> Is the jumping mainly with radio recordings?

No, it happens with all types of recordings - radio, SD and HD.
It depends on the _length_ of the recording. The recording must
be short, otherwise the effect is not visible.

> If so, that could be explained by the lastProgressUpdate timeout, because
> in radio recordings every frame is considered to be an "I-frame", while
> in video recordings I-frames are typically spaced 0.5 to 1 second.

It has nothing to with I-frames. It is solely caused by the
lastProgressUpdate timeout, which is 1 second. Try this:

Create a 2..3 minutes recording. Play it. You will see that the
progress display is not moving smoothly, because it is updated
every second.

> Let's first see whether the above patch fixes your sluggish marks display,
> and then continue with the jumping progress bar.

I am not sure if you want to implement a dynamic update of the
progress bar: The progress bar should be updated more often,
when the recording is short...

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 02.04.2018 12:35, Torgeir Veimo wrote:

Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:


At the time this was done, I was still using the TT S2-6400 as output device.


Jut curious, what are you using now? A raspberry pi?


Currently a Raspberry Pi, but I'm planning to use my J3455M board's
graphics with softhddevice (or vaapidevice).

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Torgeir Veimo]

Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:

> At the time this was done, I was still using the TT S2-6400 as output
device.

Jut curious, what are you using now? A raspberry pi?

-- 
-Tor
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 01.04.2018 19:01, Oliver Endriss wrote:

...

>> >> Does it make a difference whether the progress display is active or not
>> >> when you set the mark?
> 
> If the progress bar is off, and you set a mark, progress bar and

> mark show up immediately. -> No problem.

...
> Could it be that this action is triggered _before_ the mark has been
> written to the OSD buffer? In this case, the OSD would be displayed
> without the mark, and the mark would be displayed during the next
> cycle, i.e. one second later.

I doubt that.


Well, meanwhile I think you were right here.
In cReplayControl::MarkToggle() there is

  lastCurrent = -1; // triggers redisplay

which it used to do until the switch to GetFrameNumber() ;-).

Now this has no immediate effect any more, and that may explain
the sluggishness you observe.

Please try this:

--- menu.c  2018/03/24 11:43:40 4.70
+++ menu.c  2018/04/02 10:07:05
@@ -5728,7 +5728,7 @@
 bool cReplayControl::ShowProgress(bool Initial)
 {
   int Current, Total;
-  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+  if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - 
lastProgressUpdate >= 1) {
  if (GetFrameNumber(Current, Total) && Total > 0) {
 if (!visible) {
displayReplay = Skins.Current()->DisplayReplay(modeOnly);


I am pretty sure that something is wrong.
With the following (ugly) patch, the problem is gone:

--- vdr-2.3.9.org/menu.c2018-03-18 13:01:09.0 +0100
+++ vdr-2.3.9/menu.c2018-04-01 18:13:14.701413905 +0200
@@ -5726,7 +5726,19 @@ void cReplayControl::ShowMode(void)
  bool cReplayControl::ShowProgress(bool Initial)
  {
int Current, Total;
+
+#if 1 // OE
+  static int count = 0;
+
+  if (lastProgressUpdate == 0)
+ count = 2; // 0/1: problem, 2: fixed
+  else if (count > 0)
+ count--;
+
+  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1 || count 
> 0) {
+#else
if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+#endif
   if (GetFrameNumber(Current, Total) && Total > 0) {
  if (!visible) {
 displayReplay = Skins.Current()->DisplayReplay(modeOnly);


All it does is executing the code in 'if (Initial...)' one more time,
after lastProgressUpdate has been set to 0.


Thanks for pointing this out. This triggered my idea with lastCurrent above.


Of course, it does not affect the 'jumping' progress bar. See below.
...

> Btw, with a short recording, you can see that the progress bar is
> jumping in one second steps...

That's pretty much the distance between the I-frames, and thus the steps in
which VDR updates the progress bar.


I don't care about I-frames. I use the cutter to produce small audio
or video clips. The current behavior of the progress bar is annoying,
when I play these clips. Anyway, I can easily revert the code to get
the old behavior.


Is the jumping mainly with radio recordings?
If so, that could be explained by the lastProgressUpdate timeout, because
in radio recordings every frame is considered to be an "I-frame", while
in video recordings I-frames are typically spaced 0.5 to 1 second.

Let's first see whether the above patch fixes your sluggish marks display,
and then continue with the jumping progress bar.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:
> On 19.03.2018 18:01, Oliver Endriss wrote:
> > Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:
> >> On 19.03.2018 01:33, Oliver Endriss wrote:
> >> > Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
> >> >> On 18.03.2018 20:39, Oliver Endriss wrote:
> >> >> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> >> >> >> On 18.03.2018 18:55, Oliver Endriss wrote:
> >> >> >> > Hi,
> >> >> >> > 
> >> >> >> > just installed vdr 2.3.9 and noticed that there is a delay
> >> >> >> > when I try to set a recording mark, compared with vdr 2.2.0.
> >> >> >> > 
> >> >> >> > Steps to reproduce:
> >> >> >> > - Play a recording.
> >> >> >> > - Press ok to display the progress bar.
> >> >> >> > - Press 0 to set a mark.
> >> >> >> > 
> >> >> >> > There is a notable delay between the keypress
> >> >> >> > and the mark showing up.
> >> >> >> > 
> >> >> >> > Can someone confirm this?
> >> >> >> 
> >> >> >> Tried it while replaying on a Raspberry Pi, with the video directory
> >> >> >> mounted via NFS, and had no unusual delay.
> >> >> >> 
> >> >> >> - Which skin are you using?
> >> >> > Classic skin.
> >> >> > 
> >> >> >> - If applicable: Does it also happen with the LCARS skin?
> >> >> > Yes.
> >> >> > 
> >> >> >> - Are you running any plugins that utilize the 
> >> >> >> cStatus::MarksModified() function?
> >> >> > No. Test setup: vdr + dvbsddevice + remote.
> >> >> 
> >> >> I'm afraid I don't have a working VDR with the old FF card any more, so
> >> >> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
> >> >> though.
> >> >> 
> >> >> Does it make a difference whether the progress display is active or not
> >> >> when you set the mark?
> >> 
> >> Can you comment on this one?
> > 
> > If the progress bar is off, and you set a mark, progress bar and
> > mark show up immediately. -> No problem.
> 
> Very good!
> 
> >> >> >> - If none of the above: can you determine which version between 
> >> >> >> 2.2.0 and
> >> >> >>2.3.9 introduced this?
> >> >> > 
> >> >> > Ok. I went back in time and installed the older versions.
> >> >> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
> >> >> 
> >> >> The only change that was introduced in that area between these two 
> >> >> versions
> >> >> is in cReplayControl::ShowProgress():
> >> >> 
> >> >>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
> >> >> 
> >> >> Please try commenting out that line and the corresponding closing '}'.
> >> >> While I don't see why this would only be a problem on dvbsddevice and 
> >> >> not
> >> >> on rpihddevice, I strongly suspect it to be the culprit.
> >> > 
> >> > Yes, this fixes the issue completely!
> >> 
> >> If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).
> > 
> > So is this a workaround for the Raspberry?
> 
> Not in particular.
> At the time this was done, I was still using the TT S2-6400 as output device.

Hm, this is not required for my S2-6400.

> >> > In vdr-2.3.9 the line looks like
> >> >   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
> >> > 
> >> > As a consequence, the mark shows up immediately during fast-forward,
> >> > while it is displayed with (variable) delay in play mode.
> >> 
> >> In cReplayControl::ProcessKey() there is
> >> 
> >>if (Key != kNone)
> >>   lastProgressUpdate = 0;
> >> 
> >> so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
> >> always be true immediately after a key has been pressed ('0' in case of
> >> setting a mark).
> >> Can you verify this by adding some debug output?
> > 
> > Debug output indicates that this is true.
> > 
> > Could it be that this action is triggered _before_ the mark has been
> > written to the OSD buffer? In this case, the OSD would be displayed
> > without the mark, and the mark would be displayed during the next
> > cycle, i.e. one second later.
> 
> I doubt that.

I am pretty sure that something is wrong.
With the following (ugly) patch, the problem is gone:

--- vdr-2.3.9.org/menu.c2018-03-18 13:01:09.0 +0100
+++ vdr-2.3.9/menu.c2018-04-01 18:13:14.701413905 +0200
@@ -5726,7 +5726,19 @@ void cReplayControl::ShowMode(void)
 bool cReplayControl::ShowProgress(bool Initial)
 {
   int Current, Total;
+
+#if 1 // OE
+  static int count = 0;
+
+  if (lastProgressUpdate == 0)
+ count = 2; // 0/1: problem, 2: fixed
+  else if (count > 0)
+ count--;
+
+  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1 || 
count > 0) {
+#else
   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+#endif
  if (GetFrameNumber(Current, Total) && Total > 0) {
 if (!visible) {
displayReplay = Skins.Current()->DisplayReplay(modeOnly);


All it does is executing the code in 'if (Initial...)' one more time,
after lastProgressUpdate has been set to 0.

Of course, it does not affect 

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 19.03.2018 18:01, Oliver Endriss wrote:

Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:

On 19.03.2018 01:33, Oliver Endriss wrote:
> Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
>> On 18.03.2018 20:39, Oliver Endriss wrote:
>> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
>> >> On 18.03.2018 18:55, Oliver Endriss wrote:
>> >> > Hi,
>> >> > 
>> >> > just installed vdr 2.3.9 and noticed that there is a delay

>> >> > when I try to set a recording mark, compared with vdr 2.2.0.
>> >> > 
>> >> > Steps to reproduce:

>> >> > - Play a recording.
>> >> > - Press ok to display the progress bar.
>> >> > - Press 0 to set a mark.
>> >> > 
>> >> > There is a notable delay between the keypress

>> >> > and the mark showing up.
>> >> > 
>> >> > Can someone confirm this?
>> >> 
>> >> Tried it while replaying on a Raspberry Pi, with the video directory

>> >> mounted via NFS, and had no unusual delay.
>> >> 
>> >> - Which skin are you using?

>> > Classic skin.
>> > 
>> >> - If applicable: Does it also happen with the LCARS skin?

>> > Yes.
>> > 
>> >> - Are you running any plugins that utilize the cStatus::MarksModified() function?

>> > No. Test setup: vdr + dvbsddevice + remote.
>> 
>> I'm afraid I don't have a working VDR with the old FF card any more, so

>> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
though.
>> 
>> Does it make a difference whether the progress display is active or not

>> when you set the mark?

Can you comment on this one?


If the progress bar is off, and you set a mark, progress bar and
mark show up immediately. -> No problem.


Very good!


>> >> - If none of the above: can you determine which version between 2.2.0 and
>> >>2.3.9 introduced this?
>> > 
>> > Ok. I went back in time and installed the older versions.

>> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
>> 
>> The only change that was introduced in that area between these two versions

>> is in cReplayControl::ShowProgress():
>> 
>>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
>> 
>> Please try commenting out that line and the corresponding closing '}'.

>> While I don't see why this would only be a problem on dvbsddevice and not
>> on rpihddevice, I strongly suspect it to be the culprit.
> 
> Yes, this fixes the issue completely!


If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).


So is this a workaround for the Raspberry?


Not in particular.
At the time this was done, I was still using the TT S2-6400 as output device.


> In vdr-2.3.9 the line looks like
>   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
> 
> As a consequence, the mark shows up immediately during fast-forward,

> while it is displayed with (variable) delay in play mode.

In cReplayControl::ProcessKey() there is

   if (Key != kNone)
  lastProgressUpdate = 0;

so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
always be true immediately after a key has been pressed ('0' in case of
setting a mark).
Can you verify this by adding some debug output?


Debug output indicates that this is true.

Could it be that this action is triggered _before_ the mark has been
written to the OSD buffer? In this case, the OSD would be displayed
without the mark, and the mark would be displayed during the next
cycle, i.e. one second later.


I doubt that.

While trying to reproduce this I saw that my LIRC remote control sometimes
"misses" a keypress, which makes the whole thing appear "sluggish".
When I set/remove a mark with the '0' key on the PC's keyboard, it works
just fine every time.

Do you see any difference in behavior between the (LIRC?) remote control
and using the keyboard?


> In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
> is affected, too.
> 
> Anyway, I do not understand why rpihddevice should behave differently.

> Does this device have a slow OSD? In this case you might not notice...

The OSD on the RasPi is a lot faster than that on the old FF cards.

> I will update my dvbhddevice vdr to vdr-2.3.9 soon.
> I expect that it affected the same way.

I used a TT S2-6400 until recently (the motherboard is broken) and had no
problems setting editing marks. I'm curious to see what your experience
will be.


Update: The HD FF behaves exactly the same way as the SD FF.

Btw, with a short recording, you can see that the progress bar is
jumping in one second steps...


That's pretty much the distance between the I-frames, and thus the steps in
which VDR updates the progress bar.

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:
> On 19.03.2018 01:33, Oliver Endriss wrote:
> > Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
> >> On 18.03.2018 20:39, Oliver Endriss wrote:
> >> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> >> >> On 18.03.2018 18:55, Oliver Endriss wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > just installed vdr 2.3.9 and noticed that there is a delay
> >> >> > when I try to set a recording mark, compared with vdr 2.2.0.
> >> >> > 
> >> >> > Steps to reproduce:
> >> >> > - Play a recording.
> >> >> > - Press ok to display the progress bar.
> >> >> > - Press 0 to set a mark.
> >> >> > 
> >> >> > There is a notable delay between the keypress
> >> >> > and the mark showing up.
> >> >> > 
> >> >> > Can someone confirm this?
> >> >> 
> >> >> Tried it while replaying on a Raspberry Pi, with the video directory
> >> >> mounted via NFS, and had no unusual delay.
> >> >> 
> >> >> - Which skin are you using?
> >> > Classic skin.
> >> > 
> >> >> - If applicable: Does it also happen with the LCARS skin?
> >> > Yes.
> >> > 
> >> >> - Are you running any plugins that utilize the cStatus::MarksModified() 
> >> >> function?
> >> > No. Test setup: vdr + dvbsddevice + remote.
> >> 
> >> I'm afraid I don't have a working VDR with the old FF card any more, so
> >> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
> >> though.
> >> 
> >> Does it make a difference whether the progress display is active or not
> >> when you set the mark?
> 
> Can you comment on this one?

If the progress bar is off, and you set a mark, progress bar and
mark show up immediately. -> No problem.

> >> >> - If none of the above: can you determine which version between 2.2.0 
> >> >> and
> >> >>2.3.9 introduced this?
> >> > 
> >> > Ok. I went back in time and installed the older versions.
> >> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
> >> 
> >> The only change that was introduced in that area between these two versions
> >> is in cReplayControl::ShowProgress():
> >> 
> >>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
> >> 
> >> Please try commenting out that line and the corresponding closing '}'.
> >> While I don't see why this would only be a problem on dvbsddevice and not
> >> on rpihddevice, I strongly suspect it to be the culprit.
> > 
> > Yes, this fixes the issue completely!
> 
> If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).

So is this a workaround for the Raspberry?

> > In vdr-2.3.9 the line looks like
> >   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
> > 
> > As a consequence, the mark shows up immediately during fast-forward,
> > while it is displayed with (variable) delay in play mode.
> 
> In cReplayControl::ProcessKey() there is
> 
>if (Key != kNone)
>   lastProgressUpdate = 0;
> 
> so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
> always be true immediately after a key has been pressed ('0' in case of
> setting a mark).
> Can you verify this by adding some debug output?

Debug output indicates that this is true.

Could it be that this action is triggered _before_ the mark has been
written to the OSD buffer? In this case, the OSD would be displayed
without the mark, and the mark would be displayed during the next
cycle, i.e. one second later.

> > In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
> > is affected, too.
> > 
> > Anyway, I do not understand why rpihddevice should behave differently.
> > Does this device have a slow OSD? In this case you might not notice...
> 
> The OSD on the RasPi is a lot faster than that on the old FF cards.
> 
> > I will update my dvbhddevice vdr to vdr-2.3.9 soon.
> > I expect that it affected the same way.
> 
> I used a TT S2-6400 until recently (the motherboard is broken) and had no
> problems setting editing marks. I'm curious to see what your experience
> will be.

Update: The HD FF behaves exactly the same way as the SD FF.

Btw, with a short recording, you can see that the progress bar is
jumping in one second steps...

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 19.03.2018 01:33, Oliver Endriss wrote:

Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:

On 18.03.2018 20:39, Oliver Endriss wrote:
> Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
>> On 18.03.2018 18:55, Oliver Endriss wrote:
>> > Hi,
>> > 
>> > just installed vdr 2.3.9 and noticed that there is a delay

>> > when I try to set a recording mark, compared with vdr 2.2.0.
>> > 
>> > Steps to reproduce:

>> > - Play a recording.
>> > - Press ok to display the progress bar.
>> > - Press 0 to set a mark.
>> > 
>> > There is a notable delay between the keypress

>> > and the mark showing up.
>> > 
>> > Can someone confirm this?
>> 
>> Tried it while replaying on a Raspberry Pi, with the video directory

>> mounted via NFS, and had no unusual delay.
>> 
>> - Which skin are you using?

> Classic skin.
> 
>> - If applicable: Does it also happen with the LCARS skin?

> Yes.
> 
>> - Are you running any plugins that utilize the cStatus::MarksModified() function?

> No. Test setup: vdr + dvbsddevice + remote.

I'm afraid I don't have a working VDR with the old FF card any more, so
I can't test on that hardware. It doesn't happen with the Raspberry Pi, though.

Does it make a difference whether the progress display is active or not
when you set the mark?


Can you comment on this one?


>> - If none of the above: can you determine which version between 2.2.0 and
>>2.3.9 introduced this?
> 
> Ok. I went back in time and installed the older versions.

> Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.

The only change that was introduced in that area between these two versions
is in cReplayControl::ShowProgress():

   if (Initial || time(NULL) - lastProgressUpdate >= 1) {

Please try commenting out that line and the corresponding closing '}'.
While I don't see why this would only be a problem on dvbsddevice and not
on rpihddevice, I strongly suspect it to be the culprit.


Yes, this fixes the issue completely!


If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).


In vdr-2.3.9 the line looks like
  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)

As a consequence, the mark shows up immediately during fast-forward,
while it is displayed with (variable) delay in play mode.


In cReplayControl::ProcessKey() there is

  if (Key != kNone)
 lastProgressUpdate = 0;

so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
always be true immediately after a key has been pressed ('0' in case of
setting a mark).
Can you verify this by adding some debug output?


In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
is affected, too.

Anyway, I do not understand why rpihddevice should behave differently.
Does this device have a slow OSD? In this case you might not notice...


The OSD on the RasPi is a lot faster than that on the old FF cards.


I will update my dvbhddevice vdr to vdr-2.3.9 soon.
I expect that it affected the same way.


I used a TT S2-6400 until recently (the motherboard is broken) and had no
problems setting editing marks. I'm curious to see what your experience
will be.

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
> On 18.03.2018 20:39, Oliver Endriss wrote:
> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> >> On 18.03.2018 18:55, Oliver Endriss wrote:
> >> > Hi,
> >> > 
> >> > just installed vdr 2.3.9 and noticed that there is a delay
> >> > when I try to set a recording mark, compared with vdr 2.2.0.
> >> > 
> >> > Steps to reproduce:
> >> > - Play a recording.
> >> > - Press ok to display the progress bar.
> >> > - Press 0 to set a mark.
> >> > 
> >> > There is a notable delay between the keypress
> >> > and the mark showing up.
> >> > 
> >> > Can someone confirm this?
> >> 
> >> Tried it while replaying on a Raspberry Pi, with the video directory
> >> mounted via NFS, and had no unusual delay.
> >> 
> >> - Which skin are you using?
> > Classic skin.
> > 
> >> - If applicable: Does it also happen with the LCARS skin?
> > Yes.
> > 
> >> - Are you running any plugins that utilize the cStatus::MarksModified() 
> >> function?
> > No. Test setup: vdr + dvbsddevice + remote.
> 
> I'm afraid I don't have a working VDR with the old FF card any more, so
> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
> though.
> 
> Does it make a difference whether the progress display is active or not
> when you set the mark?
> 
> >> - If none of the above: can you determine which version between 2.2.0 and
> >>2.3.9 introduced this?
> > 
> > Ok. I went back in time and installed the older versions.
> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
> 
> The only change that was introduced in that area between these two versions
> is in cReplayControl::ShowProgress():
> 
>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
> 
> Please try commenting out that line and the corresponding closing '}'.
> While I don't see why this would only be a problem on dvbsddevice and not
> on rpihddevice, I strongly suspect it to be the culprit.

Yes, this fixes the issue completely!

In vdr-2.3.9 the line looks like
 if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)

As a consequence, the mark shows up immediately during fast-forward,
while it is displayed with (variable) delay in play mode.

In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
is affected, too.

Anyway, I do not understand why rpihddevice should behave differently.
Does this device have a slow OSD? In this case you might not notice...

I will update my dvbhddevice vdr to vdr-2.3.9 soon.
I expect that it affected the same way.

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 18.03.2018 20:39, Oliver Endriss wrote:

Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:

On 18.03.2018 18:55, Oliver Endriss wrote:
> Hi,
> 
> just installed vdr 2.3.9 and noticed that there is a delay

> when I try to set a recording mark, compared with vdr 2.2.0.
> 
> Steps to reproduce:

> - Play a recording.
> - Press ok to display the progress bar.
> - Press 0 to set a mark.
> 
> There is a notable delay between the keypress

> and the mark showing up.
> 
> Can someone confirm this?


Tried it while replaying on a Raspberry Pi, with the video directory
mounted via NFS, and had no unusual delay.

- Which skin are you using?

Classic skin.


- If applicable: Does it also happen with the LCARS skin?

Yes.


- Are you running any plugins that utilize the cStatus::MarksModified() 
function?

No. Test setup: vdr + dvbsddevice + remote.


I'm afraid I don't have a working VDR with the old FF card any more, so
I can't test on that hardware. It doesn't happen with the Raspberry Pi, though.

Does it make a difference whether the progress display is active or not
when you set the mark?


- If none of the above: can you determine which version between 2.2.0 and
   2.3.9 introduced this?


Ok. I went back in time and installed the older versions.
Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.


The only change that was introduced in that area between these two versions
is in cReplayControl::ShowProgress():

  if (Initial || time(NULL) - lastProgressUpdate >= 1) {

Please try commenting out that line and the corresponding closing '}'.
While I don't see why this would only be a problem on dvbsddevice and not
on rpihddevice, I strongly suspect it to be the culprit.

If you like, we can continue this in private.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Klaus Schmidinger]

On 18.03.2018 18:55, Oliver Endriss wrote:

Hi,

just installed vdr 2.3.9 and noticed that there is a delay
when I try to set a recording mark, compared with vdr 2.2.0.

Steps to reproduce:
- Play a recording.
- Press ok to display the progress bar.
- Press 0 to set a mark.

There is a notable delay between the keypress
and the mark showing up.

Can someone confirm this?


Tried it while replaying on a Raspberry Pi, with the video directory
mounted via NFS, and had no unusual delay.

- Which skin are you using?
- If applicable: Does it also happen with the LCARS skin?
- Are you running any plugins that utilize the cStatus::MarksModified() 
function?
- If none of the above: can you determine which version between 2.2.0 and
  2.3.9 introduced this?

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Teemu Suikki]

2018-01-21 15:46 GMT+02:00 Klaus Schmidinger :
> As long as a cPlayer (or a cReceiver, for that matter) is attached to
> a cDevice, VDR will not perform its housekeeping tasks. This is to
> avoid any problems during replay or recording, possibly caused by
> heavy disk access.

Ah, I see.. I think softhddevice uses the dummy player to receive
keypresses, so it can exit from suspend on demand.

But the full check in vdr.c is this:

   if ((Now - LastInteract) > ACTIVITYTIMEOUT &&
!cRecordControls::Active() && !RecordingsHandler.Active() &&
!Interface->HasSVDRPConnection() && (Now - cRemote::LastActivity()) >
ACTIVITYTIMEOUT) {


So, there is a separate check for active recordings, and user activity
(cRemote)..

I think I just remove the LastInteract check. I think it is not really
useful on my current system anyway. I have a commercial detector
running after each recording, and it will run no matter what.. There
could be another active recording going, or playback or whatever. VDR
housekeeping is a  much lighter process.

And currently the check works pretty much the wrong way around.. :) If
softhddevice is suspended and vdr left "idle", it will never enter
housekeeping because of the check.

-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Klaus Schmidinger]

On 19.01.2018 18:48, Teemu Suikki wrote:

I'm starting to think that maybe my problem IS caused entirely by this
softhddevice bug. Because my softhddevice keep freezing quite
frequently, I have added a shutdown command that detaches softhddevice
and leaves vdr running. And then when I watch something, I'm pressing
buttons and using menus and there might be timers recording etc, so
vdr never becomes idle enough to do the housekeeping?

I tried to understand the code, but I'm having difficulties. :) in
vdr.c, only place that sets LastInteract is this:

 Interact = Menu ? Menu : cControl::Control(); // might have
been closed in the mean time
 if (Interact) {
LastInteract = Now;
eOSState state = Interact->ProcessKey(key);
if (state == osUnknown && Interact != cControl::Control()) {

So.. Does this mean that softhddevice's dummy player has menu open all
the time? softhddevice.cpp doesn't have really anything menu-related
in the dummy player, all those methods must be inherited from main vdr
class.

Only thing that looks suspicious is this, dummy player's ProcessKey:

eOSState cSoftHdControl::ProcessKey(eKeys key)
{
 if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key)
 || key == kMenu || key == kBack || key == kStop)) {
 delete Player;

 Player = NULL;
 Resume();
 SuspendMode = NOT_SUSPENDED;
 return osEnd;
 }
 return osContinue;
}

Should it really return osContinue all the time?


As long as a cPlayer (or a cReceiver, for that matter) is attached to
a cDevice, VDR will not perform its housekeeping tasks. This is to
avoid any problems during replay or recording, possibly caused by
heavy disk access.

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Petri Hintukainen]

Hello,

pe, 2018-01-19 kello 19:48 +0200, Teemu Suikki kirjoitti:
> I'm starting to think that maybe my problem IS caused entirely by
> this
> softhddevice bug. Because my softhddevice keep freezing quite
> frequently, I have added a shutdown command that detaches
> softhddevice
> and leaves vdr running. And then when I watch something, I'm pressing
> buttons and using menus and there might be timers recording etc, so
> vdr never becomes idle enough to do the housekeeping?
> 
> I tried to understand the code, but I'm having difficulties. :) in
> vdr.c, only place that sets LastInteract is this:
> 
> Interact = Menu ? Menu : cControl::Control(); // might have
> been closed in the mean time
> if (Interact) {
>LastInteract = Now;
>eOSState state = Interact->ProcessKey(key);
>if (state == osUnknown && Interact != cControl::Control())
> {
> 
> So.. Does this mean that softhddevice's dummy player has menu open
> all
> the time? softhddevice.cpp doesn't have really anything menu-related
> in the dummy player, all those methods must be inherited from main
> vdr class.
> 
> Only thing that looks suspicious is this, dummy player's ProcessKey:
> 
> eOSState cSoftHdControl::ProcessKey(eKeys key)
> {
> if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key)
> || key == kMenu || key == kBack || key == kStop)) {
> delete Player;
> 
> Player = NULL;
> Resume();
> SuspendMode = NOT_SUSPENDED;
> return osEnd;
> }
> return osContinue;
> }

Looks like the plugin has some kind of dummy player open. If I remember
right, housekeeping tasks are not handled (by design) when you have a
player open.

I think I had to work around similar issues when I wrote suspendoutput
plugin. It was quite a while ago (2005-09-20: Added vdr idle actions)
so I don't remember all the details anymore ...

Anyway, the plugin is relatively simple:
http://phivdr.dyndns.org/vdr/vdr-suspendoutput/suspendoutput-2.1.0/susp
endoutput.c

Housekeeping tasks are handled in MainThreadHook() and
CheckInactivityTimer().

> Should it really return osContinue all the time?
>
> 
> 2018-01-18 23:37 GMT+02:00 Klaus Schmidinger  de>:
> > On 18.01.2018 21:26, Teemu Suikki wrote:
> > > 
> > > Ok, I did some debugging.
> > > 
> > > First of all, I noticed something weird that perhaps is not even
> > > related to this problem. In vdr.c there is a check:
> > > 
> > >   if ((Now - LastInteract) > ACTIVITYTIMEOUT
> > > 
> > > if softhhddevice is detached or suspended, "Now - LastInteract"
> > > is
> > > always zero, and vdr can never enter housekeeping tasks. This
> > > must be
> > > a bug in softhddevice?
> > 
> > 
> > I guess so.
> > 
> > 
> > Klaus
> > 
> > 
> > ___
> > vdr mailing list
> > vdr@linuxtv.org
> > https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
> 
> 

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Teemu Suikki]

I'm starting to think that maybe my problem IS caused entirely by this
softhddevice bug. Because my softhddevice keep freezing quite
frequently, I have added a shutdown command that detaches softhddevice
and leaves vdr running. And then when I watch something, I'm pressing
buttons and using menus and there might be timers recording etc, so
vdr never becomes idle enough to do the housekeeping?

I tried to understand the code, but I'm having difficulties. :) in
vdr.c, only place that sets LastInteract is this:

Interact = Menu ? Menu : cControl::Control(); // might have
been closed in the mean time
if (Interact) {
   LastInteract = Now;
   eOSState state = Interact->ProcessKey(key);
   if (state == osUnknown && Interact != cControl::Control()) {

So.. Does this mean that softhddevice's dummy player has menu open all
the time? softhddevice.cpp doesn't have really anything menu-related
in the dummy player, all those methods must be inherited from main vdr
class.

Only thing that looks suspicious is this, dummy player's ProcessKey:

eOSState cSoftHdControl::ProcessKey(eKeys key)
{
if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key)
|| key == kMenu || key == kBack || key == kStop)) {
delete Player;

Player = NULL;
Resume();
SuspendMode = NOT_SUSPENDED;
return osEnd;
}
return osContinue;
}

Should it really return osContinue all the time?


2018-01-18 23:37 GMT+02:00 Klaus Schmidinger :
> On 18.01.2018 21:26, Teemu Suikki wrote:
>>
>> Ok, I did some debugging.
>>
>> First of all, I noticed something weird that perhaps is not even
>> related to this problem. In vdr.c there is a check:
>>
>>   if ((Now - LastInteract) > ACTIVITYTIMEOUT
>>
>> if softhhddevice is detached or suspended, "Now - LastInteract" is
>> always zero, and vdr can never enter housekeeping tasks. This must be
>> a bug in softhddevice?
>
>
> I guess so.
>
>
> Klaus
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Klaus Schmidinger]

On 18.01.2018 21:26, Teemu Suikki wrote:

Ok, I did some debugging.

First of all, I noticed something weird that perhaps is not even
related to this problem. In vdr.c there is a check:

  if ((Now - LastInteract) > ACTIVITYTIMEOUT

if softhhddevice is detached or suspended, "Now - LastInteract" is
always zero, and vdr can never enter housekeeping tasks. This must be
a bug in softhddevice?


I guess so.

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Teemu Suikki]

Ok, I did some debugging.

First of all, I noticed something weird that perhaps is not even
related to this problem. In vdr.c there is a check:

 if ((Now - LastInteract) > ACTIVITYTIMEOUT

if softhhddevice is detached or suspended, "Now - LastInteract" is
always zero, and vdr can never enter housekeeping tasks. This must be
a bug in softhddevice?

But, with softhddevice attached, housekeeping starts after 60 seconds.
However, now with the added debug, I could not reproduce the original
problem. :) VDR always deletes my recordings nicely. But now I have
the debug enabled, in case it happens again.






2018-01-18 12:26 GMT+02:00 Klaus Schmidinger :
> On 18.01.2018 08:54, Teemu Suikki wrote:
>>
>> Ok, it might be the same thing.
>>
>> I added some debug as Klaus suggested. After restart, vdr instantly
>> deleted a few directories.. So at least it works sometimes. :)
>>
>> Perhaps the cleanup fails if Plex or another vdr is currently accessing
>> the same files? Maybe vdr then thinks it has deleted them, and does not try
>> again.
>
>
> In cRemoveDeletedRecordingsThread::Action() VDR tries to get a lock on the
> video directory. If this fails, it can't remove deleted recordings.
>
> Please add some debug output to this function, to see whether it is called
> and whether it gets the lock. If it doesn't get the lock while Plex is
> running, try without Plex.
>
> Klaus
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[VDR User]

> My video directory is nfs-mounted to a raspberry pi running another vdr.  In
> my case, I have not changed the configuration in any way, but despite of
> daily usage, this has not reoccurred.  So either some other patch fixed the
> problem for me, or this is some extremely rarely happening race condition
> type thing.

Just for reference, my recordings directory is also an nfs share but I
don't recall ever experiencing this issue.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Klaus Schmidinger]

On 18.01.2018 08:54, Teemu Suikki wrote:

Ok, it might be the same thing.

I added some debug as Klaus suggested. After restart, vdr instantly deleted a 
few directories.. So at least it works sometimes. :)

Perhaps the cleanup fails if Plex or another vdr is currently accessing the 
same files? Maybe vdr then thinks it has deleted them, and does not try again.


In cRemoveDeletedRecordingsThread::Action() VDR tries to get a lock on the
video directory. If this fails, it can't remove deleted recordings.

Please add some debug output to this function, to see whether it is called
and whether it gets the lock. If it doesn't get the lock while Plex is
running, try without Plex.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Teemu Suikki]

Ok, it might be the same thing.

I added some debug as Klaus suggested. After restart, vdr instantly deleted
a few directories.. So at least it works sometimes. :)

Perhaps the cleanup fails if Plex or another vdr is currently accessing the
same files? Maybe vdr then thinks it has deleted them, and does not try
again.

17.1.2018 22.28 "Jouni Karvo"  kirjoitti:

> Klaus Schmidinger kirjoitti 17.01.2018 klo 11:59:
>
>> On 16.01.2018 19:44, Teemu Suikki wrote:
>>
>>> Hi,
>>>
>>> I just experienced weird problem. My hard drive became 100% full.
>>>
>>>
>>> ...
>
>> This is somehow related to the fact that I now have Plex Media Server
>>> sitting on the VDR recordings directory. But still I could remove the
>>> .del directories easily from the command line. After manually deleting
>>> them, disk is now only 85% full.. And that's 4TB drive. :) So there
>>> were quite a bit of .del directories.
>>>
>>
>> Do you have anything going on that causes frequent "user ineraction" with
>> VDR?
>>
>
> I had a similar problem some time ago (I don't remember how many years,
> but with vdr 2.2.0).  I reported on this mailing list then, but I did not
> find that email with a short search, now.
>
> My video directory is nfs-mounted to a raspberry pi running another vdr.
> In my case, I have not changed the configuration in any way, but despite of
> daily usage, this has not reoccurred.  So either some other patch fixed the
> problem for me, or this is some extremely rarely happening race condition
> type thing.
>
> yours,
> Jouni
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Jouni Karvo]

Klaus Schmidinger kirjoitti 17.01.2018 klo 11:59:

On 16.01.2018 19:44, Teemu Suikki wrote:

Hi,

I just experienced weird problem. My hard drive became 100% full.



...

This is somehow related to the fact that I now have Plex Media Server
sitting on the VDR recordings directory. But still I could remove the
.del directories easily from the command line. After manually deleting
them, disk is now only 85% full.. And that's 4TB drive. :) So there
were quite a bit of .del directories.


Do you have anything going on that causes frequent "user ineraction" with
VDR? 


I had a similar problem some time ago (I don't remember how many years, 
but with vdr 2.2.0).  I reported on this mailing list then, but I did 
not find that email with a short search, now.


My video directory is nfs-mounted to a raspberry pi running another 
vdr.  In my case, I have not changed the configuration in any way, but 
despite of daily usage, this has not reoccurred.  So either some other 
patch fixed the problem for me, or this is some extremely rarely 
happening race condition type thing.


yours,
    Jouni

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[Klaus Schmidinger]

On 16.01.2018 19:44, Teemu Suikki wrote:

Hi,

I just experienced weird problem. My hard drive became 100% full.

But I noticed that there are tons of .del directories, some dating
from months ago.. VDR hasn't removed them! What could cause this?

I see entries in log:
low disk space while recording, trying to remove a deleted recording...
Jan 16 08:23:06 puucee vdr: [30504] removing recording xxx.del

And these recordings ARE removed really. But the normal background
cleaning does not happen.

This is somehow related to the fact that I now have Plex Media Server
sitting on the VDR recordings directory. But still I could remove the
.del directories easily from the command line. After manually deleting
them, disk is now only 85% full.. And that's 4TB drive. :) So there
were quite a bit of .del directories.


Do you have anything going on that causes frequent "user ineraction" with
VDR?

Try adding some debug output to RemoveDeletedRecordings() and maybe also to
cRemoveDeletedRecordingsThread::Action() (both in recording.c) to find out
what might be causing this.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

Any ideas how to get this fixed? This is really getting on my nerves now.

I now detach softhddevice always when I stop watching. It does not
freeze then. But sometimes it freezes right after I attach it! Just a
few seconds of working video and BANG frozen. Really annoying!

Another thing which might be related. On my earlier setup, if I paused
playback, softhddevice would mute the sound. On this setup, audio is
not muted, it is looping the last buffer until playback continues.
That also is an annoying feature. :)

I'm pretty sure I have exact same versions of all VDR software and
plugins, only things changed are the Linux kernel, TBS media drivers,
and possibly the nvidia vdpau drivers.. Everything worked just fine
earlier!






2017-12-09 3:05 GMT+02:00 VDR User :
>> It still does lock up.
>>
>> I think it is really softhddevice problem, as the lockup only happens
>> if actually viewing the channel.. My VDR box is always on, and usually
>> I just turn off the projector and leave VDR running. Perhaps I need to
>> change my habits and actually suspend softhddevice when not really
>> watching it.
>
> Ideally you should be able to run VDR 24/7 without issue. That's what
> I do and have no intention of changing the habit. Unfortunately
> softhddevice is no longer actively developed by its' author but there
> are still some coders in the VDR community who have helped keep it
> updated. It's possible they may be able to help fix this bug if enough
> information can be provided. In my cause the frozen/defunct VDR seems
> to occur if I lose signal for some unknown length of time, and doesn't
> seem related to audio. Fortunately it's the only problem I have and it
> doesn't happen daily. It would however be great if it were fixed -
> hopefully we'll get to that point.
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

It still does lock up.

I think it is really softhddevice problem, as the lockup only happens
if actually viewing the channel.. My VDR box is always on, and usually
I just turn off the projector and leave VDR running. Perhaps I need to
change my habits and actually suspend softhddevice when not really
watching it.

Some log, not really useful though. It starts with the "TS packet not
accepted", which now only appears once because of the modification
Klaus suggested. But there's still a lot of other output that is
probably the cause of the lockup.

One thing that came to mind. In my previous setup with much older
kernel and DVB drivers, sometimes VDR/softhddevice lost audio
completely when left running for a long time. Video was running but no
audio. Audio only came back after suspend/resume of softhddevice,
channel switch didn't wake it up. Perhaps this is the same bug, but
now it keeps going trying to restart audio?


Dec  8 20:22:56 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:22:56 puucee vdr: [20880] ERROR: TS packet not accepted in
Transfer Mode
Dec  8 20:22:56 puucee vdr: audio/alsa: using device 'default'
Dec  8 20:22:56 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:22:56 puucee vdr: audio/alsa: start delay 1000ms
Dec  8 20:22:56 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:22:56 puucee vdr: audio/alsa: using device 'default'
Dec  8 20:22:56 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:22:56 puucee vdr: audio/alsa: start delay 1000ms
Dec  8 20:22:56 puucee vdr: audio/alsa: using device 'default'

That is continued for hundreds of lines, then this:

Dec  8 20:22:59 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:22:59 puucee vdr: audio/alsa: start delay 1000ms
Dec  8 20:22:59 puucee vdr: [20881] buffer usage: 70% (tid=20880)
Dec  8 20:22:59 puucee vdr: [20880] [softhddev]Clear:

later 80%, 90%, 100%

After that new kind of errors:

Dec  8 20:23:01 puucee vdr: [20880] ERROR: skipped 60 bytes to sync on
start of TS packet
Dec  8 20:23:01 puucee vdr: audio/alsa: start delay 1000ms
Dec  8 20:23:01 puucee vdr: [20880] ERROR: skipped 64 bytes to sync on
start of TS packet
Dec  8 20:23:01 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:23:01 puucee vdr: [20880] ERROR: skipped 64 bytes to sync on
start of TS packet
Dec  8 20:23:01 puucee vdr: audio/alsa: using device 'default'
Dec  8 20:23:01 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:23:01 puucee vdr: audio/alsa: start delay 1000ms



Dec  8 20:23:03 puucee vdr: [20881] ERROR: driver buffer overflow on device 4
Dec  8 20:23:03 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:23:03 puucee vdr: audio/alsa: start delay 1000ms



Dec  8 20:28:02 puucee vdr: [20880] ERROR: skipped 13 bytes to sync on
start of TS packet
Dec  8 20:28:02 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:28:02 puucee vdr: audio: can't set channels 2 sample-rate 0Hz
Dec  8 20:28:02 puucee vdr: [20880] ERROR: skipped 179 bytes to sync
on start of TS packet

That 0Hz error is now also repeated for the rest of the log..

at 20:35 I restarted vdr:

Dec  8 20:35:42 puucee vdr: [20880] ERROR: skipped 92 bytes to sync on
start of TS packet
Dec  8 20:35:42 puucee vdr: [20880] [softhddev]Clear:
Dec  8 20:35:42 puucee vdr: audio: can't set channels 2 sample-rate 0Hz
Dec  8 20:35:42 puucee vdr: [20880] ERROR: skipped 188 bytes to sync
on start of TS packet
Dec  8 20:35:42 puucee vdr: [20880] ERROR: skipped 188 bytes to sync
on start of TS packet
Dec  8 20:35:42 puucee systemd[1]: vdr.service: State 'stop-sigterm'
timed out. Killing.
Dec  8 20:35:42 puucee systemd[1]: vdr.service: Main process exited,
code=killed, status=9/KILL
Dec  8 20:35:42 puucee systemd[1]: Stopped Video Disk Recorder.


Before restart, I used the "femon" command on shell, and all my tuners
showed good signal with no errors and locked state... So, even if the
problem might be started by some error in the stream, it surely should
correct itself? Maybe try retuning with different tuner instead of
throwing 3000 lines of errors to log? :)



2017-11-27 20:04 GMT+02:00 Teemu Suikki :
> I now switched to the open source TBS drivers. They seem more stable
> than the official proprietary drivers.. So hopefully this problem is
> gone too.
>
> But sadly Klaus' change is now untested, TS error did not occur even
> once today with old drivers. We'll see what happens with new ones. :)
>
> 2017-11-27 17:24 GMT+02:00 VDR User :
 I made this change few hours ago, but I'm still waiting for the
 problem to appear.. Obviously it now is working 100%. :)
>>
>> Same here.
>>
>>> Does "working 100%" mean that youre not getting any of these error
>>> messages any more? Not even once?
>>
>> I'm not getting them right now either but it only means the conditions
>> that cause it haven't occurred yet. It will though - it always does
>> sooner or later unfortunately.
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> 

Re: [vdr] VDR locking up

[VDR User]

>> I made this change few hours ago, but I'm still waiting for the
>> problem to appear.. Obviously it now is working 100%. :)

Same here.

> Does "working 100%" mean that youre not getting any of these error
> messages any more? Not even once?

I'm not getting them right now either but it only means the conditions
that cause it haven't occurred yet. It will though - it always does
sooner or later unfortunately.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

yes, that's exactly what it means. :) Just bad (or good!) luck.
Yesterday it got stuck three times during the day.

The weather is better today. I think the error is caused by weak signal..


2017-11-27 12:04 GMT+02:00 Klaus Schmidinger :
> On 27.11.2017 09:04, Teemu Suikki wrote:
>>
>>
>> I made this change few hours ago, but I'm still waiting for the
>> problem to appear.. Obviously it now is working 100%. :)
>
>
> Does "working 100%" mean that youre not getting any of these error
> messages any more? Not even once?
>
> Klaus
>
>
>> 2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :
>>>
>>> On 26.11.2017 19:09, Teemu Suikki wrote:


 I know I'm replying to a year old thread, but I'm having the exact same
 problem.

 I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
 drivers to latest version.. Now I have this problem, that randomly VDR
 starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
 log. It will not jam right away, but after maybe 30-60min it is
 jammed.

 Some VDR functions like timers seem to still work, but the GUI is stuck.

 This is VDR 2.2.0 from yavdr repos.

 Any ideas?

 Even though this might be a driver bug, perhaps vdr of softhddevice
 could simply stop displaying the channel after the first error?
>>>
>>>
>>>
>>> I can't contribute anything regarding the driver or softhddevice,
>>> but I guess limiting the log message to, say, one message per minute
>>> could save the program from getting stuck.
>>> That's assuming your log is actually flooded with thousands of
>>> entries like that.
>>> To qickly verify this could you please precede the line
>>>
>>>   esyslog("ERROR: TS packet not accepted in Transfer Mode");
>>>
>>> in transfer.c with
>>>
>>>   static int Counter = 0;
>>>   if ((Counter++ % 1) == 0)
>>>
>>> Klaus
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Klaus Schmidinger]

On 27.11.2017 09:04, Teemu Suikki wrote:


I made this change few hours ago, but I'm still waiting for the
problem to appear.. Obviously it now is working 100%. :)


Does "working 100%" mean that youre not getting any of these error
messages any more? Not even once?

Klaus


2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :

On 26.11.2017 19:09, Teemu Suikki wrote:


I know I'm replying to a year old thread, but I'm having the exact same
problem.

I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
drivers to latest version.. Now I have this problem, that randomly VDR
starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
log. It will not jam right away, but after maybe 30-60min it is
jammed.

Some VDR functions like timers seem to still work, but the GUI is stuck.

This is VDR 2.2.0 from yavdr repos.

Any ideas?

Even though this might be a driver bug, perhaps vdr of softhddevice
could simply stop displaying the channel after the first error?



I can't contribute anything regarding the driver or softhddevice,
but I guess limiting the log message to, say, one message per minute
could save the program from getting stuck.
That's assuming your log is actually flooded with thousands of
entries like that.
To qickly verify this could you please precede the line

  esyslog("ERROR: TS packet not accepted in Transfer Mode");

in transfer.c with

  static int Counter = 0;
  if ((Counter++ % 1) == 0)

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

Thanks!

I made this change few hours ago, but I'm still waiting for the
problem to appear.. Obviously it now is working 100%. :)

I now also got the open source TBS drivers to build properly, if they
work nicely I might switch over. Perhaps it fixes this too.


2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :
> On 26.11.2017 19:09, Teemu Suikki wrote:
>>
>> I know I'm replying to a year old thread, but I'm having the exact same
>> problem.
>>
>> I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
>> drivers to latest version.. Now I have this problem, that randomly VDR
>> starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
>> log. It will not jam right away, but after maybe 30-60min it is
>> jammed.
>>
>> Some VDR functions like timers seem to still work, but the GUI is stuck.
>>
>> This is VDR 2.2.0 from yavdr repos.
>>
>> Any ideas?
>>
>> Even though this might be a driver bug, perhaps vdr of softhddevice
>> could simply stop displaying the channel after the first error?
>
>
> I can't contribute anything regarding the driver or softhddevice,
> but I guess limiting the log message to, say, one message per minute
> could save the program from getting stuck.
> That's assuming your log is actually flooded with thousands of
> entries like that.
> To qickly verify this could you please precede the line
>
>   esyslog("ERROR: TS packet not accepted in Transfer Mode");
>
> in transfer.c with
>
>   static int Counter = 0;
>   if ((Counter++ % 1) == 0)
>
> Klaus
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Klaus Schmidinger]

On 26.11.2017 19:09, Teemu Suikki wrote:

I know I'm replying to a year old thread, but I'm having the exact same problem.

I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
drivers to latest version.. Now I have this problem, that randomly VDR
starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
log. It will not jam right away, but after maybe 30-60min it is
jammed.

Some VDR functions like timers seem to still work, but the GUI is stuck.

This is VDR 2.2.0 from yavdr repos.

Any ideas?

Even though this might be a driver bug, perhaps vdr of softhddevice
could simply stop displaying the channel after the first error?


I can't contribute anything regarding the driver or softhddevice,
but I guess limiting the log message to, say, one message per minute
could save the program from getting stuck.
That's assuming your log is actually flooded with thousands of
entries like that.
To qickly verify this could you please precede the line

  esyslog("ERROR: TS packet not accepted in Transfer Mode");

in transfer.c with

  static int Counter = 0;
  if ((Counter++ % 1) == 0)

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

I know I'm replying to a year old thread, but I'm having the exact same problem.

I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
drivers to latest version.. Now I have this problem, that randomly VDR
starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
log. It will not jam right away, but after maybe 30-60min it is
jammed.

Some VDR functions like timers seem to still work, but the GUI is stuck.

This is VDR 2.2.0 from yavdr repos.

Any ideas?

Even though this might be a driver bug, perhaps vdr of softhddevice
could simply stop displaying the channel after the first error?


2016-10-29 19:32 GMT+03:00 VDR User :
> Hi and thanks for your reply. Currently the kernel is 4.8.4 stable,
> gp8psk kernel driver, vdr-2.2.0. However, this problem has been going
> on for quite a while - I'm just now getting around to asking about it.
> The drivers I use haven't been changed in years so I'm not sure that's
> where the root cause is. It's interesting that you've experienced it
> as well with a completely different card/drivers. I wonder if
> downgrading your drivers really had any affect of it the conditions
> which cause the problem to surface just haven't happened yet.
> Hopefully others will chime in as well and we can get to the bottom of
> it. It may be an infrequent problem but it has a nasty result!
>
> -Derek
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-2.2.0 compilation fails with gcc7

[Martin Gansser]

Thanks for your patch, but then there are further error messages:

g++ -O3 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 
-mtune=generic -fPIC -Werror=overloaded-virtual -Wno-parentheses -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fPIC -c 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
-DREMOTE_KBD -DVDR_USER=\"vdr\" -DSDNOTIFY 
-DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/var/lib/vdr/video\" 
-DCONFDIR=\"/etc/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" 
-DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/share/vdr\" 
-DPLUGINDIR=\"/usr/lib64/vdr\" -DLOCDIR=\"/usr/share/locale\" 
-I/usr/include/freetype2 -I/usr/include/libpng16-o osdbase.o osdbase.c
osdbase.c: In member function 'eOSState cOsdMenu::HotKey(eKeys)':
osdbase.c:513:38: error: ISO C++ forbids comparison between pointer and integer 
[-fpermissive]
   if (s && (s = skipspace(s)) != '\0' && '0' <= s[i] && s[i] <= '9') {
  ^~~~
make: *** [Makefile:126: osdbase.o] Error 1

I fixed this with this patch:

--- a/osdbase.c.orig2017-02-15 15:55:34.555128665 +0100
+++ b/osdbase.c 2017-02-15 15:56:30.898068614 +0100
@@ -510,7 +510,7 @@
   const char *s = item->Text();
   i = 0;
   item_nr = 0;
-  if (s && (s = skipspace(s)) != '\0' && '0' <= s[i] && s[i] <= '9') {
+  if (s && (s = skipspace(s)) != NULL && '0' <= s[i] && s[i] <= '9') {
  do {
 item_nr = item_nr * 10 + (s[i] - '0');
 }

it compiles fine, but I am not shure if this is correct ?
 
 

Gesendet: Donnerstag, 02. März 2017 um 11:35 Uhr
Von: "Klaus Schmidinger" <klaus.schmidin...@tvdr.de>
An: "VDR Mailing List" <vdr@linuxtv.org>
Betreff: Re: [vdr] vdr-2.2.0 compilation fails with gcc7
On 02.03.2017 11:25, Martin Gansser wrote:
> vdr-2.2.0 compilation fails with gcc7 on Fedora26.
> ...

This will be fixed in version 2.3.3, where I have changed "unsigned"
to "signed" in several places to avoid these problems.
Attached are the respective changes, it still applies to version 2.2.0.

Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-2.2.0 compilation fails with gcc7

[Klaus Schmidinger]

On 02.03.2017 11:25, Martin Gansser wrote:

vdr-2.2.0 compilation fails with gcc7 on Fedora26.
...


This will be fixed in version 2.3.3, where I have changed "unsigned"
to "signed" in several places to avoid these problems.
Attached are the respective changes, it still applies to version 2.2.0.

Klaus
--- diseqc.c	2015/01/26 12:02:14	4.0
+++ diseqc.c	2017/01/09 15:10:40
@@ -253,10 +253,10 @@
   return result;
 }
 
-uint cDiseqc::SetScrFrequency(uint SatFrequency, const cScr *Scr, uint8_t *Codes) const
+int cDiseqc::SetScrFrequency(int SatFrequency, const cScr *Scr, uint8_t *Codes) const
 {
   if ((Codes[0] & 0xF0) == 0x70 ) { // EN50607 aka JESS
- uint t = SatFrequency == 0 ? 0 : (SatFrequency - 100);
+ int t = SatFrequency == 0 ? 0 : (SatFrequency - 100);
  if (t < 2048 && Scr->Channel() >= 0 && Scr->Channel() < 32) {
 Codes[1] = t >> 8 | Scr->Channel() << 3;
 Codes[2] = t;
@@ -266,7 +266,7 @@
 }
  }
   else { // EN50494 aka Unicable
- uint t = SatFrequency == 0 ? 0 : (SatFrequency + Scr->UserBand() + 2) / 4 - 350; // '+ 2' together with '/ 4' results in rounding!
+ int t = SatFrequency == 0 ? 0 : (SatFrequency + Scr->UserBand() + 2) / 4 - 350; // '+ 2' together with '/ 4' results in rounding!
  if (t < 1024 && Scr->Channel() >= 0 && Scr->Channel() < 8) {
 Codes[3] = t >> 8 | (t == 0 ? 0 : scrBank << 2) | Scr->Channel() << 5;
 Codes[4] = t;
@@ -399,7 +399,7 @@
   return NULL;
 }
 
-cDiseqc::eDiseqcActions cDiseqc::Execute(const char **CurrentAction, uchar *Codes, uint8_t *MaxCodes, const cScr *Scr, uint *Frequency) const
+cDiseqc::eDiseqcActions cDiseqc::Execute(const char **CurrentAction, uchar *Codes, uint8_t *MaxCodes, const cScr *Scr, int *Frequency) const
 {
   if (!*CurrentAction)
  *CurrentAction = commands;
--- diseqc.h	2013/06/12 11:52:17	4.0
+++ diseqc.h	2017/01/09 15:11:19
@@ -86,7 +86,7 @@
   mutable int scrBank;
   char *commands;
   bool parsing;
-  uint SetScrFrequency(uint SatFrequency, const cScr *Scr, uint8_t *Codes) const;
+  int SetScrFrequency(int SatFrequency, const cScr *Scr, uint8_t *Codes) const;
   int SetScrPin(const cScr *Scr, uint8_t *Codes) const;
   const char *Wait(const char *s) const;
   const char *GetPosition(const char *s) const;
@@ -96,7 +96,7 @@
   cDiseqc(void);
   ~cDiseqc();
   bool Parse(const char *s);
-  eDiseqcActions Execute(const char **CurrentAction, uchar *Codes, uint8_t *MaxCodes, const cScr *Scr, uint *Frequency) const;
+  eDiseqcActions Execute(const char **CurrentAction, uchar *Codes, uint8_t *MaxCodes, const cScr *Scr, int *Frequency) const;
   ///< Parses the DiSEqC commands and returns the appropriate action code
   ///< with every call. CurrentAction must be the address of a character pointer,
   ///< which is initialized to NULL. This pointer is used internally while parsing
--- dvbdevice.c	2016/11/07 13:55:58	4.3
+++ dvbdevice.c	2017/01/09 15:11:39
@@ -329,7 +329,7 @@
   void ClearEventQueue(void) const;
   bool GetFrontendStatus(fe_status_t ) const;
   cPositioner *GetPositioner(void);
-  void ExecuteDiseqc(const cDiseqc *Diseqc, unsigned int *Frequency);
+  void ExecuteDiseqc(const cDiseqc *Diseqc, int *Frequency);
   void ResetToneAndVoltage(void);
   bool SetFrontend(void);
   virtual void Action(void);
@@ -696,7 +696,7 @@
   return positioner;
 }
 
-void cDvbTuner::ExecuteDiseqc(const cDiseqc *Diseqc, unsigned int *Frequency)
+void cDvbTuner::ExecuteDiseqc(const cDiseqc *Diseqc, int *Frequency)
 {
   if (!lnbPowerTurnedOn) {
  CHECK(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13)); // must explicitly turn on LNB power
@@ -806,7 +806,7 @@
 
   SETCMD(DTV_DELIVERY_SYSTEM, frontendType);
   if (frontendType == SYS_DVBS || frontendType == SYS_DVBS2) {
- unsigned int frequency = channel.Frequency();
+ int frequency = channel.Frequency();
  if (Setup.DiSEqC) {
 if (const cDiseqc *diseqc = Diseqcs.Get(device->CardIndex() + 1, channel.Source(), frequency, dtp.Polarization(), )) {
frequency -= diseqc->Lof();
@@ -829,7 +829,7 @@
 }
  else {
 int tone = SEC_TONE_OFF;
-if (frequency < (unsigned int)Setup.LnbSLOF) {
+if (frequency < Setup.LnbSLOF) {
frequency -= Setup.LnbFrequLo;
tone = SEC_TONE_OFF;
}
--- remux.c	2016/12/22 12:58:20	4.3
+++ remux.c	2017/01/09 15:05:05
@@ -1629,7 +1629,7 @@
   Div += parser->IFrameTemporalReferenceOffset();
if (Div <= 0)
   Div = 1;
-   uint32_t Delta = ptsValues[0] / Div;
+   int Delta = ptsValues[0] / Div;
// determine frame info:
if (isVideo) {
   if (Delta == 3753)
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR without PrimaryDVB but with xineliboutput ?

[Niedermeier Günter]

Was there anything in the log when vdr-sxfe was started / stopped ?


I can not say, because I forgot to/didn't look at any log.

I'll give it a try with the new suspendoutput plugin.

Thank you

-Wanninger

---




--
This message was scanned by ESVA and is believed to be clean.


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR without PrimaryDVB but with xineliboutput ?

[Petri Hintukainen]

ti, 2017-01-17 kello 17:37 +0100, Niedermeier Günter kirjoitti:
> > Recent xineliboutput can trigger suspendoutput automatically when
> > vdr-
> > sxfe is disconnected (this could use some testing ...). See --auto-
> > suspend option.
> 
> Is it enough to replace the xineliboutput plugin with the latest git-
> version
> and start the plugin it with "-s" parameter,  or must I do further
> things?

You need also recent vdr-suspedoutput plugin loaded:
https://phivdr.dyndns.org/vdr/vdr-suspendoutput/vdr-suspendoutput-2.1.0
.tgz

> Only updating the xineliboutput plugin does not trigger autosuspend
> yet.
> (At least in my environment)

Was there anything in the log when vdr-sxfe was started / stopped ?

It should trigger suspendoutput when there are no clients, and disable
it when a client connects. But, as said, this is not much tested
feature :)

> -Wanninger
> 
> 
> --
> This message was scanned by ESVA and is believed to be clean.
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr