Hi
When I'm watching TV with one of the RPI's and want to move to the other RPI, I cannot change the channel from what the first RPI was viewing. I am not sure how to tell streamdev to stop streaming so that I can watch TV on the other RPI? I hope I've been clear with that - it does sound a bit confusing. I know there is a mainmenu entry that says suspend server, but it didn't seem to do anything, unless its done in the background.
Especially for devices like Raspberry Pi it would be very nice to have kind of a "standby" function in VDR, which detaches active receivers and call an appropriate function on the primary device to suspend and blank the output. Then resuming VDR would only take a fraction of a second...
In regards to the rpihddevice I am seeing some tearing or 'flutter' when there is high motion with 1080 HD. Its not so bad that it isn't usable - it most certainly works 99% of the time just fine.
Have you set the HDMI frame rate according your video format?
The one feature I miss with the rpihddevice that softhddevice had was the automatic zoom - hoping that gets added to the wish list at some point.
I'm afraid this might take a while, since accessing the decoded image is not that easy, however possible. But rpihddevice supports the ScaleVideo() method, so in principle it's possible to do it manually.
Regards, Thomas
On Tue, Jul 08, 2014 at 12:59:58PM +0200, Thomas Reufer wrote:
Especially for devices like Raspberry Pi it would be very nice to have kind of a "standby" function in VDR, which detaches active receivers and call an appropriate function on the primary device to suspend and blank the output. Then resuming VDR would only take a fraction of a second...
I guess that for the cheap ARM boards such as the Raspberry Pi, it is simplest to keep the base hardware "always on" (the base power consumption being so low, and because there is no battery-backed clock or wakeup timer).
Like you say, it would be useful if the tuners and also the HDMI output were suspended.
I wonder if it is possible to detect if anything is connected to the HDMI output and powered on? If the HDMI attached display is disconnected or powered off, it would make sense to suspend the video and audio output (also on the electrical level) and detach all receivers that are not being used for any recordings.
For what it is worth, when I started using softdevice (not softhddevice) several years ago, I developed a method that allows the video decoding to be suspended when there is no interactive user (the system got nvram-wakeup by timer, not by the user pressing the Power button). With a software decoder, it is not only about power savings; it is also about avoiding crashes when the decoder is buggy and you get a glitch in the signal. I am still using the years-old hardware. I am interested in upgrading to something ARM-based (Cubieboard?) at some point, maybe when USB DVB-T2 dongles become commodity (shortly after DVB-T2 is introduced in Germany, I hope).
Marko
Hi Marko,
Am 08.07.14 13:34, schrieb Marko Mäkelä:
Like you say, it would be useful if the tuners and also the HDMI output were suspended.
I wonder if it is possible to detect if anything is connected to the HDMI output and powered on? If the HDMI attached display is disconnected or powered off, it would make sense to suspend the video and audio output (also on the electrical level) and detach all receivers that are not being used for any recordings.
I like this idea :-)
According to this http://www.raspberrypi.org/forums/viewtopic.php?&t=18292 post it is possible to detect if a monitor is connected. Not sure what happens if the monitor is switched off...
Maybe tvservice can also be used (http://elinux.org/RPiconfig): # /opt/vc/bin/tvservice -m CEA Group CEA has 0 modes:
# /opt/vc/bin/tvservice -m DMT Group DMT has 0 modes:
with no monitor connected. Unfortunately I'm not at home so I can't try out what happens if you connect a monitor, switch in on/off, etc...
For what it is worth, when I started using softdevice (not softhddevice) several years ago, I developed a method that allows the video decoding to be suspended when there is no interactive user (the system got nvram-wakeup by timer, not by the user pressing the Power button). With a software decoder, it is not only about power savings; it is also about avoiding crashes when the decoder is buggy and you get a glitch in the signal. I am still using the years-old hardware. I am interested in
Are you still using the old softdevice? I would have never guessed someone is still using it :-)
I must admit that I switched to the xineliboutput plugin years ago. I was missing the network features...
upgrading to something ARM-based (Cubieboard?) at some point, maybe when USB DVB-T2 dongles become commodity (shortly after DVB-T2 is introduced in Germany, I hope).
I'm using an ARM-Based Qnap-NAS as vdr server, it works really well with an USB DVB-T Dual-Tuner, and xineliboutput. I'm in the process of upgrading to a Cubietruck and a raspberry pi as client, but due to lack of time I have not got very far.
Cheers,
Martin
Oh, hi, Martin! Long time no see.
Are you still using the old softdevice? I would have never guessed someone is still using it :-)
Yes! I was in "stealth mode" for several years, until I finally upgraded the software (Debian+VDR) from 2006 less than a year ago.
I tried to contribute some patches to make softdevice work with current VDR. It seemed that the mailing list archive was corrupted. I have been thinking of cloning the old CVS repository and committing my patches on top of it. Not that I expect anyone else to use it. It is mainly for preserving the history. :) Do you have any tips how to do that?
I'm using an ARM-Based Qnap-NAS as vdr server, it works really well with an USB DVB-T Dual-Tuner, and xineliboutput. I'm in the process of upgrading to a Cubietruck and a raspberry pi as client, but due to lack of time I have not got very far.
OK, I see. I would prefer an all-in-one solution (HDMI output, DVB-T input, Ethernet and hard disk in a single device). This would seem to be doable with an ARM board that supports SATA devices. On the RPi I would not expect it to work, due to everything sharing the single USB bus.
Another interesting development is this plugin that I sometimes use with my Samsung SmartTV: http://projects.vdr-developer.org/projects/plg-smarttvweb/. I basically only use softdevice on speakerless VGA monitor for cutting recordings.
Marko
----Origineel Bericht---- Van : marko.makela@iki.fi Datum : 08/07/2014 14:22 Aan : vdr@linuxtv.org Onderwerp : Re: [vdr] Raspberry Pi, Streamdev + rpihddevice
Oh, hi, Martin! Long time no see.
Are you still using the old softdevice? I would have never guessed someone is still using it :-)
Yes! I was in "stealth mode" for several years, until I finally upgraded the software (Debian+VDR) from 2006 less than a year ago.
I tried to contribute some patches to make softdevice work with current VDR. It seemed that the mailing list archive was corrupted. I have been thinking of cloning the old CVS repository and committing my patches on top of it. Not that I expect anyone else to use it. It is mainly for preserving the history. :) Do you have any tips how to do that?
I'm using an ARM-Based Qnap-NAS as vdr server, it works really well with an USB DVB-T Dual-Tuner, and xineliboutput. I'm in the process of upgrading to a Cubietruck and a raspberry pi as client, but due to lack of time I have not got very far.
OK, I see. I would prefer an all-in-one solution (HDMI output, DVB-T input, Ethernet and hard disk in a single device). This would seem to be doable with an ARM board that supports SATA devices. On the RPi I would not expect it to work, due to everything sharing the single USB bus.
I am also building an all in one box based on the olinux allwinner A20 board. I have everything working (DVB-T, digitenne decoding, SATA, HDMI playback). I have connected 3 DVB-T receivers via a hub on one USB port, and the board happily recorded 3 shows, one per receiver.
I am still struggling howto get accelerated video playback going. Now the A20 uses 70% CPU to playback a SD stream. I will look into using the android driver with a linux wrapper around it. It should be doable, somebody on this list reported success (but I didn't ask him for a howto)
The board can be clocked from 90MHz .. 1GHz. I have yet to measure the power consumption, but the chip gets quite hot (about 80 degrees) when running at 1GHz continuously without heat sink.
Kind regards, Cedric
I am still struggling howto get accelerated video playback going. Now the A20 uses 70% CPU to playback a SD stream. I will look into using the android driver with a linux wrapper around it. It should be doable, somebody on this list reported success (but I didn't ask him for a howto)
The board can be clocked from 90MHz .. 1GHz. I have yet to measure the power consumption, but the chip gets quite hot (about 80 degrees) when running at 1GHz continuously without heat sink.
How stable is it overclocked that high? Also, how long have you been doing that? I don't know what the thermal tolerance is for the A20 but doesn't low power design not play nice with high temps? I would think without adding at least some cooling, overclocking that much will send it to see the grim reaper much much sooner...?
On Tue, Jul 08, 2014 at 05:01:15PM +0200, cedric.dewijs@telfort.nl wrote:
OK, I see. I would prefer an all-in-one solution (HDMI output, DVB-T input, Ethernet and hard disk in a single device). This would seem to be doable with an ARM board that supports SATA devices. On the RPi I would not expect it to work, due to everything sharing the single USB bus.
I am also building an all in one box based on the olinux allwinner A20 board. I have everything working (DVB-T, digitenne decoding, SATA, HDMI playback). I have connected 3 DVB-T receivers via a hub on one USB port, and the board happily recorded 3 shows, one per receiver.
I wonder if the recently announced Raspberry Pi Model B+ would work as an all-in-one solution. While the hardware is almost identical (same SoC, same amount of RAM), the USB side got improved a little. It looks like it now got an integrated 4-port USB hub that can supply enough power for a 2.5" hard disk and a DVB-T tuner, provided that you use a strong enough power supply. This would eliminate one box (powered USB hub) from the setup.
Other changes between the Raspberry Pi Model B and B+ are that the GPIO connector got extended, the circuit board grew a little, and the analog AV output was removed). The changed circuit board dimensions will probably mean that it will take a while until cases become available. And you would still need at least 2 cases: one for the Raspberry and another for the USB hard disk.
But, the question remains if it is possible to record something and watch something else at the same time, or if the single USB bus of the Raspberry gets congested too easily?
I am still struggling howto get accelerated video playback going. Now the A20 uses 70% CPU to playback a SD stream. I will look into using the android driver with a linux wrapper around it. It should be doable, somebody on this list reported success (but I didn't ask him for a howto)
Good luck. Do you have a case for the A20 where you can install a SATA disk?
The board can be clocked from 90MHz .. 1GHz. I have yet to measure the power consumption, but the chip gets quite hot (about 80 degrees) when running at 1GHz continuously without heat sink.
Have you considered glueing a small heat sink on the chip? Is there any metal case for the A20 board that would act as a heat sink for the SoC? I guess that this would already improve things, even if you do not install a fan.
Marko
On Tue, Jul 08, 2014 at 02:34:37PM +0300, Marko Mäkelä wrote:
I guess that for the cheap ARM boards such as the Raspberry Pi, it is simplest to keep the base hardware "always on" (the base power consumption being so low, and because there is no battery-backed clock or wakeup timer).
I'm using a switchable power strip for my xineliboutput player, the TV set and everything else. :-)
Thanks for the good info in this thread. I have done a couple of things. I have configured irexec and the power off in vdr to shutdown vdr on the client, and another button to start up vdr. That seems to do the trick for the time being. Also I've matched the framerate from video to TV and it is much better - thanks Thomas!
I have 2 other issues with the RPI: On an older LCD with a buggy edid, when I turn off the TV, then turn it back on I must reset the RPI at just the right time to get video back. It doesn't seem to be sending an HDMI command to reset (or whatever command it needs) at any point. Also on this older TV, any non-2 channel audio is being heard. Anyone know how to downgrade 5 or 6 channel sound to 2 channel for proper HDMI out?
Regarding shutdown based on whether the TV is on or not, perhaps CEC could help in most instances. In my case with the one older TV it wouldn't help but that's my problem. :)
Norm
On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer thomas@reufer.ch wrote:
Hi
When I'm watching TV with one of the RPI's and want to move to the other RPI, I cannot change the channel from what the first RPI was viewing. I
am
not sure how to tell streamdev to stop streaming so that I can watch TV
on
the other RPI? I hope I've been clear with that - it does sound a bit confusing. I know there is a mainmenu entry that says suspend server,
but
it didn't seem to do anything, unless its done in the background.
Especially for devices like Raspberry Pi it would be very nice to have kind of a "standby" function in VDR, which detaches active receivers and call an appropriate function on the primary device to suspend and blank the output. Then resuming VDR would only take a fraction of a second...
In regards to the rpihddevice I am seeing some tearing or 'flutter' when there is high motion with 1080 HD. Its not so bad that it isn't usable - it most certainly works 99% of the time just fine.
Have you set the HDMI frame rate according your video format?
The one feature I miss with the rpihddevice that softhddevice had was the automatic zoom -
hoping
that gets added to the wish list at some point.
I'm afraid this might take a while, since accessing the decoded image is not that easy, however possible. But rpihddevice supports the ScaleVideo() method, so in principle it's possible to do it manually.
Regards, Thomas
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
There's also the "suspendoutput" plugin. I don't know, where its upstream is currently located, but it's available in the yavdr-PPA:
https://launchpad.net/~yavdr/+archive/ubuntu/unstable-vdr/+sourcepub/4067463...
As far as I know it stops live TV so the device (streamdev-client in this case) has no receivers anymore and the server is free for another client.
Regards, Lars.
Am 08.07.2014 15:41, schrieb Norm Dressler:
Thanks for the good info in this thread. I have done a couple of things. I have configured irexec and the power off in vdr to shutdown vdr on the client, and another button to start up vdr. That seems to do the trick for the time being. Also I've matched the framerate from video to TV and it is much better - thanks Thomas!
I have 2 other issues with the RPI: On an older LCD with a buggy edid, when I turn off the TV, then turn it back on I must reset the RPI at just the right time to get video back. It doesn't seem to be sending an HDMI command to reset (or whatever command it needs) at any point. Also on this older TV, any non-2 channel audio is being heard. Anyone know how to downgrade 5 or 6 channel sound to 2 channel for proper HDMI out?
Regarding shutdown based on whether the TV is on or not, perhaps CEC could help in most instances. In my case with the one older TV it wouldn't help but that's my problem. :)
Norm
On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer <thomas@reufer.ch mailto:thomas@reufer.ch> wrote:
Hi > When I'm watching TV with one of the RPI's and want to move to the other > RPI, I cannot change the channel from what the first RPI was viewing. I am > not sure how to tell streamdev to stop streaming so that I can watch TV on > the other RPI? I hope I've been clear with that - it does sound a bit > confusing. I know there is a mainmenu entry that says suspend server, but > it didn't seem to do anything, unless its done in the background. Especially for devices like Raspberry Pi it would be very nice to have kind of a "standby" function in VDR, which detaches active receivers and call an appropriate function on the primary device to suspend and blank the output. Then resuming VDR would only take a fraction of a second... > In regards to the rpihddevice I am seeing some tearing or 'flutter' when > there is high motion with 1080 HD. Its not so bad that it isn't usable - > it most certainly works 99% of the time just fine. Have you set the HDMI frame rate according your video format? > The one feature I miss > with the rpihddevice that softhddevice had was the automatic zoom - hoping > that gets added to the wish list at some point. I'm afraid this might take a while, since accessing the decoded image is not that easy, however possible. But rpihddevice supports the ScaleVideo() method, so in principle it's possible to do it manually. Regards, Thomas _______________________________________________ vdr mailing list vdr@linuxtv.org <mailto: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
Am 09.07.2014 18:47, schrieb Lars Hanisch:
Hi,
There's also the "suspendoutput" plugin. I don't know, where its upstream is currently located, but it's available in the yavdr-PPA:
https://launchpad.net/~yavdr/+archive/ubuntu/unstable-vdr/+sourcepub/4067463...
vdr-wiki is back online, here's the official source:
http://phivdr.dyndns.org/vdr/vdr-suspendoutput/
Lars.
As far as I know it stops live TV so the device (streamdev-client in this case) has no receivers anymore and the server is free for another client.
Regards, Lars.
Am 08.07.2014 15:41, schrieb Norm Dressler:
Thanks for the good info in this thread. I have done a couple of things. I have configured irexec and the power off in vdr to shutdown vdr on the client, and another button to start up vdr. That seems to do the trick for the time being. Also I've matched the framerate from video to TV and it is much better - thanks Thomas!
I have 2 other issues with the RPI: On an older LCD with a buggy edid, when I turn off the TV, then turn it back on I must reset the RPI at just the right time to get video back. It doesn't seem to be sending an HDMI command to reset (or whatever command it needs) at any point. Also on this older TV, any non-2 channel audio is being heard. Anyone know how to downgrade 5 or 6 channel sound to 2 channel for proper HDMI out?
Regarding shutdown based on whether the TV is on or not, perhaps CEC could help in most instances. In my case with the one older TV it wouldn't help but that's my problem. :)
Norm
On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer <thomas@reufer.ch mailto:thomas@reufer.ch> wrote:
Hi > When I'm watching TV with one of the RPI's and want to move to the other > RPI, I cannot change the channel from what the first RPI was viewing. I am > not sure how to tell streamdev to stop streaming so that I can watch TV on > the other RPI? I hope I've been clear with that - it does sound a bit > confusing. I know there is a mainmenu entry that says suspend server, but > it didn't seem to do anything, unless its done in the background. Especially for devices like Raspberry Pi it would be very nice to have kind of a "standby" function in VDR, which detaches active receivers and call an appropriate function on the primary device to suspend and blank the output. Then resuming VDR would only take a fraction of a second... > In regards to the rpihddevice I am seeing some tearing or 'flutter' when > there is high motion with 1080 HD. Its not so bad that it isn't usable - > it most certainly works 99% of the time just fine. Have you set the HDMI frame rate according your video format? > The one feature I miss > with the rpihddevice that softhddevice had was the automatic zoom - hoping > that gets added to the wish list at some point. I'm afraid this might take a while, since accessing the decoded image is not that easy, however possible. But rpihddevice supports the ScaleVideo() method, so in principle it's possible to do it manually. Regards, Thomas _______________________________________________ vdr mailing list vdr@linuxtv.org <mailto: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
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
What I have done is lowered the priority to the streamdev-client in one room, and leaving the priority high in my main room. The main room RPI is powered by the TV USB port so with my programable remote I insert a 10 second delay between issuing the poweroff command to the rpi and powering off the TV (which removes power from the RPI). This seems to have resolved my contention issues.
On Wed, Jul 9, 2014 at 3:20 PM, Lars Hanisch dvb@flensrocker.de wrote:
Am 09.07.2014 18:47, schrieb Lars Hanisch:
Hi,
There's also the "suspendoutput" plugin. I don't know, where its
upstream is currently located, but it's available in
the yavdr-PPA:
https://launchpad.net/~yavdr/+archive/ubuntu/unstable-vdr/+sourcepub/4067463...
vdr-wiki is back online, here's the official source:
http://phivdr.dyndns.org/vdr/vdr-suspendoutput/
Lars.
As far as I know it stops live TV so the device (streamdev-client in
this case) has no receivers anymore and the server
is free for another client.
Regards, Lars.
Am 08.07.2014 15:41, schrieb Norm Dressler:
Thanks for the good info in this thread. I have done a couple of
things. I have configured irexec and the power off in
vdr to shutdown vdr on the client, and another button to start up vdr.
That seems to do the trick for the time being.
Also I've matched the framerate from video to TV and it is much better
- thanks Thomas!
I have 2 other issues with the RPI: On an older LCD with a buggy edid, when I turn off the TV, then turn it
back on I must reset the RPI at just the right
time to get video back. It doesn't seem to be sending an HDMI command
to reset (or whatever command it needs) at any
point. Also on this older TV, any non-2 channel audio is being heard. Anyone
know how to downgrade 5 or 6 channel sound to 2
channel for proper HDMI out?
Regarding shutdown based on whether the TV is on or not, perhaps CEC
could help in most instances. In my case with the
one older TV it wouldn't help but that's my problem. :)
Norm
On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer <thomas@reufer.ch
mailto:thomas@reufer.ch> wrote:
Hi > When I'm watching TV with one of the RPI's and want to move tothe other
> RPI, I cannot change the channel from what the first RPI wasviewing. I am
> not sure how to tell streamdev to stop streaming so that I canwatch TV on
> the other RPI? I hope I've been clear with that - it does sounda bit
> confusing. I know there is a mainmenu entry that says suspendserver, but
> it didn't seem to do anything, unless its done in the background. Especially for devices like Raspberry Pi it would be very nice tohave kind of a "standby" function in VDR, which
detaches active receivers and call an appropriate function on theprimary device to suspend and blank the output.
Then resuming VDR would only take a fraction of a second... > In regards to the rpihddevice I am seeing some tearing or'flutter' when
> there is high motion with 1080 HD. Its not so bad that it isn'tusable -
> it most certainly works 99% of the time just fine. Have you set the HDMI frame rate according your video format? > The one feature I miss > with the rpihddevice that softhddevice had was the automatic zoom
- hoping
> that gets added to the wish list at some point. I'm afraid this might take a while, since accessing the decodedimage is not that easy, however possible. But
rpihddevice supports the ScaleVideo() method, so in principle it'spossible to do it manually.
Regards, Thomas _______________________________________________ vdr mailing list vdr@linuxtv.org <mailto: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
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
Hi all, well, I upgraded my rpihddevice to the git repository and see that you have added a 'zoom' type feature for SD - that's awesome!
New problem though, with 1080i atsc, I'm getting screen blanking every 20 seconds or so. It's fine with 480i with the deinterlacer enabled (as per the log). 720p also works fine with deinterlacer disabled. I can't find anything in the log files that might help with troubleshooting this problem.
Not sure if this is a known issue or not...
Thanks Norm
On Wed, Jul 9, 2014 at 3:24 PM, Norm Dressler norm.dressler@gmail.com wrote:
What I have done is lowered the priority to the streamdev-client in one room, and leaving the priority high in my main room. The main room RPI is powered by the TV USB port so with my programable remote I insert a 10 second delay between issuing the poweroff command to the rpi and powering off the TV (which removes power from the RPI). This seems to have resolved my contention issues.
On Wed, Jul 9, 2014 at 3:20 PM, Lars Hanisch dvb@flensrocker.de wrote:
Am 09.07.2014 18:47, schrieb Lars Hanisch:
Hi,
There's also the "suspendoutput" plugin. I don't know, where its
upstream is currently located, but it's available in
the yavdr-PPA:
https://launchpad.net/~yavdr/+archive/ubuntu/unstable-vdr/+sourcepub/4067463...
vdr-wiki is back online, here's the official source:
http://phivdr.dyndns.org/vdr/vdr-suspendoutput/
Lars.
As far as I know it stops live TV so the device (streamdev-client in
this case) has no receivers anymore and the server
is free for another client.
Regards, Lars.
Am 08.07.2014 15:41, schrieb Norm Dressler:
Thanks for the good info in this thread. I have done a couple of
things. I have configured irexec and the power off in
vdr to shutdown vdr on the client, and another button to start up vdr.
That seems to do the trick for the time being.
Also I've matched the framerate from video to TV and it is much better
- thanks Thomas!
I have 2 other issues with the RPI: On an older LCD with a buggy edid, when I turn off the TV, then turn
it back on I must reset the RPI at just the right
time to get video back. It doesn't seem to be sending an HDMI command
to reset (or whatever command it needs) at any
point. Also on this older TV, any non-2 channel audio is being heard. Anyone
know how to downgrade 5 or 6 channel sound to 2
channel for proper HDMI out?
Regarding shutdown based on whether the TV is on or not, perhaps CEC
could help in most instances. In my case with the
one older TV it wouldn't help but that's my problem. :)
Norm
On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer <thomas@reufer.ch
mailto:thomas@reufer.ch> wrote:
Hi > When I'm watching TV with one of the RPI's and want to move tothe other
> RPI, I cannot change the channel from what the first RPI wasviewing. I am
> not sure how to tell streamdev to stop streaming so that I canwatch TV on
> the other RPI? I hope I've been clear with that - it does sounda bit
> confusing. I know there is a mainmenu entry that says suspendserver, but
> it didn't seem to do anything, unless its done in the background. Especially for devices like Raspberry Pi it would be very nice tohave kind of a "standby" function in VDR, which
detaches active receivers and call an appropriate function on theprimary device to suspend and blank the output.
Then resuming VDR would only take a fraction of a second... > In regards to the rpihddevice I am seeing some tearing or'flutter' when
> there is high motion with 1080 HD. Its not so bad that it isn'tusable -
> it most certainly works 99% of the time just fine. Have you set the HDMI frame rate according your video format? > The one feature I miss > with the rpihddevice that softhddevice had was the automaticzoom - hoping
> that gets added to the wish list at some point. I'm afraid this might take a while, since accessing the decodedimage is not that easy, however possible. But
rpihddevice supports the ScaleVideo() method, so in principle it'spossible to do it manually.
Regards, Thomas _______________________________________________ vdr mailing list vdr@linuxtv.org <mailto: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
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
Hi Norm
Am 15.07.2014 um 01:44 schrieb Norm Dressler norm.dressler@gmail.com:
New problem though, with 1080i atsc, I'm getting screen blanking every 20 seconds or so. It's fine with 480i with the deinterlacer enabled (as per the log). 720p also works fine with deinterlacer disabled. I can't find anything in the log files that might help with troubleshooting this problem.
There's a HDMI boost option in config.txt you might want to try:
# Config HDMI Boost # Configures the signal strength of the HDMI interface. Default is 0. Try 4 if # you have interference issues (or blanking or no display) with hdmi. config_hdmi_boost=4 #Set to change signal strength (0 - 7)
Regards, Thomas
New problem though, with 1080i atsc, I'm getting screen blanking every 20 seconds or so. It's fine with 480i with the deinterlacer enabled (as per the log). 720p also works fine with deinterlacer disabled. I can't find anything in the log files that might help with troubleshooting this problem.
There's a HDMI boost option in config.txt you might want to try:
# Config HDMI Boost # Configures the signal strength of the HDMI interface. Default is 0. Try 4 if # you have interference issues (or blanking or no display) with hdmi. config_hdmi_boost=4 #Set to change signal strength (0 - 7)
What exactly is the purpose of that? A way to reduce power consumption by giving hdmi only enough signal/power it needs per your setup?
It was already set to 6. I tried 7 with no difference. It had been working fine with my Pioneer receiver up until this latest version. A direct connection to the TV seems to work with my other setup.
Norm
On Tue, Jul 15, 2014 at 3:15 AM, VDR User user.vdr@gmail.com wrote:
New problem though, with 1080i atsc, I'm getting screen blanking every
20 seconds or so. It's fine with 480i with the deinterlacer enabled (as per the log). 720p also works fine with deinterlacer disabled. I can't find anything in the log files that might help with troubleshooting this problem.
There's a HDMI boost option in config.txt you might want to try:
# Config HDMI Boost # Configures the signal strength of the HDMI interface. Default is 0.
Try 4 if
# you have interference issues (or blanking or no display) with hdmi. config_hdmi_boost=4 #Set to change signal strength (0 - 7)
What exactly is the purpose of that? A way to reduce power consumption by giving hdmi only enough signal/power it needs per your setup?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi Norm
It was already set to 6. I tried 7 with no difference. It had been working fine with my Pioneer receiver up until this latest version. A direct connection to the TV seems to work with my other setup.
What's the exact version you've been using before? I'm not aware of any recent changes in this area, but if you encounter these problems only during live-TV, you might try this patch:
diff --git a/omxdevice.c b/omxdevice.c index 6ccb113..b006f44 100644 --- a/omxdevice.c +++ b/omxdevice.c @@ -32,7 +32,7 @@ int cOmxDevice::s_speeds[2][8] = {
// speed correction factors for live mode, taken from omxplayer int cOmxDevice::s_speedCorrections[5] = { - S(0.990f), S(0.999f), S(1.000f), S(1.001), S(1.010) + S(0.995f), S(0.999f), S(1.000f), S(1.001), S(1.005) };
cOmxDevice::cOmxDevice(void (*onPrimaryDevice)(void)) :
During live-TV the OMX clock is permanently adjusted to keep it in sync with the DVB stream. The method as well as the correction factors I've taken from omxplayer without knowing how big the deviation is actually allowed to be, since it's also affecting the HDMI clock. The above patch changes the maximum value from +/- 1% to +/- 0.5%.
Regards, Thomas
Thanks for the quick response. I had downloaded a tarball of 0.0.5 and I believe the git version I have is 0.0.9.
I applied the patch but I'm still getting the disruptions - where it was blanking the screen before it seems to be 'glitching' and occasionally blanking.
Norm
On Tue, Jul 15, 2014 at 7:54 AM, Thomas Reufer thomas@reufer.ch wrote:
Hi Norm
It was already set to 6. I tried 7 with no difference. It had been
working fine with my Pioneer receiver up until this latest version. A direct connection to the TV seems to work with my other setup.
What's the exact version you've been using before? I'm not aware of any recent changes in this area, but if you encounter these problems only during live-TV, you might try this patch:
diff --git a/omxdevice.c b/omxdevice.c index 6ccb113..b006f44 100644 --- a/omxdevice.c +++ b/omxdevice.c @@ -32,7 +32,7 @@ int cOmxDevice::s_speeds[2][8] = {
// speed correction factors for live mode, taken from omxplayer int cOmxDevice::s_speedCorrections[5] = {
S(0.990f), S(0.999f), S(1.000f), S(1.001), S(1.010)
S(0.995f), S(0.999f), S(1.000f), S(1.001), S(1.005)};
cOmxDevice::cOmxDevice(void (*onPrimaryDevice)(void)) :
During live-TV the OMX clock is permanently adjusted to keep it in sync with the DVB stream. The method as well as the correction factors I've taken from omxplayer without knowing how big the deviation is actually allowed to be, since it's also affecting the HDMI clock. The above patch changes the maximum value from +/- 1% to +/- 0.5%.
Regards, Thomas
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 15.07.2014 um 14:08 schrieb Norm Dressler norm.dressler@gmail.com:
Thanks for the quick response. I had downloaded a tarball of 0.0.5 and I believe the git version I have is 0.0.9.
Well, 0.0.5 was quite long time ago… ;-)
I applied the patch but I'm still getting the disruptions - where it was blanking the screen before it seems to be 'glitching' and occasionally blanking.
Could you please try plain 0.0.9 without the latest patches in git? And some more information would be really helpful… whether it happens only on live-TV, your audio settings, config.txt, etc...
Furthermore I'd try to play a file with omxplayer to see, whether it's related to the plugin or to your setup.
Regards, Thomas
Trying these things now. I had installed that version of rpihddevice only because the how-to I followed linked to it :) I will record some of the HD stream in question and then try and replay it both within VDR and from omxplayer.
my config.txt:
hdmi_force_hotplug=1
hdmi_group=1 hdmi_mode=16
config_hdmi_boost=2
gpu_mem=256
decode_MPG2=xxxxxxxxx decode_WVC1=xxxxxxxxx
On Tue, Jul 15, 2014 at 10:35 AM, Thomas Reufer thomas@reufer.ch wrote:
Am 15.07.2014 um 14:08 schrieb Norm Dressler norm.dressler@gmail.com:
Thanks for the quick response. I had downloaded a tarball of 0.0.5 and
I believe the git version I have is 0.0.9.
Well, 0.0.5 was quite long time ago… ;-)
I applied the patch but I'm still getting the disruptions - where it was
blanking the screen before it seems to be 'glitching' and occasionally blanking.
Could you please try plain 0.0.9 without the latest patches in git? And some more information would be really helpful… whether it happens only on live-TV, your audio settings, config.txt, etc...
Furthermore I'd try to play a file with omxplayer to see, whether it's related to the plugin or to your setup.
Regards, Thomas
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Ok, so I'm back to the released version of 0.0.9 (not GIT). It does the same thing - blanks the screen, etc. I recorded the channel for a bit to see if it happens with the recording and it does happen with the recording. I think exited VDR and ran omxplayer directly with the TS file and it did NOT have the same problem. No glitches or blanking.
The video is 1080i with AC3 6-channel audio. The RPI is plugged into a Pioneer VX-1023 receiver, which in turn is connected to the LG 3d LED tv. Audio is configured to go out HDMI with passthrough enabled.
If there is any other information I can get for you just let me know.
Norm
On Tue, Jul 15, 2014 at 12:38 PM, Norm Dressler norm.dressler@gmail.com wrote:
Trying these things now. I had installed that version of rpihddevice only because the how-to I followed linked to it :) I will record some of the HD stream in question and then try and replay it both within VDR and from omxplayer.
my config.txt:
hdmi_force_hotplug=1
hdmi_group=1 hdmi_mode=16
config_hdmi_boost=2
gpu_mem=256
decode_MPG2=xxxxxxxxx decode_WVC1=xxxxxxxxx
On Tue, Jul 15, 2014 at 10:35 AM, Thomas Reufer thomas@reufer.ch wrote:
Am 15.07.2014 um 14:08 schrieb Norm Dressler norm.dressler@gmail.com:
Thanks for the quick response. I had downloaded a tarball of 0.0.5 and
I believe the git version I have is 0.0.9.
Well, 0.0.5 was quite long time ago… ;-)
I applied the patch but I'm still getting the disruptions - where it
was blanking the screen before it seems to be 'glitching' and occasionally blanking.
Could you please try plain 0.0.9 without the latest patches in git? And some more information would be really helpful… whether it happens only on live-TV, your audio settings, config.txt, etc...
Furthermore I'd try to play a file with omxplayer to see, whether it's related to the plugin or to your setup.
Regards, Thomas
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 15.07.2014 um 21:30 schrieb Norm Dressler norm.dressler@gmail.com:
Ok, so I'm back to the released version of 0.0.9 (not GIT). It does the same thing - blanks the screen, etc. I recorded the channel for a bit to see if it happens with the recording and it does happen with the recording. I think exited VDR and ran omxplayer directly with the TS file and it did NOT have the same problem. No glitches or blanking.
The video is 1080i with AC3 6-channel audio. The RPI is plugged into a Pioneer VX-1023 receiver, which in turn is connected to the LG 3d LED tv. Audio is configured to go out HDMI with passthrough enabled.
If you're using pass through, could you please try to add hdmi_stream_channels=1 to config.txt? That's currently the only difference to omxplayer I'm aware of. Or, try to use analog audio, to ensure there's no HDMI-audio issue.
If the error still occurs, I'd be interested in the video file to try, whether I can reproduce the issue. If you have the possibility to upload the file somewhere, please let me know via PM.
Regards, Thomas
-
cedric.dewijs＠telfort.nl -
Harald Milz -
Lars Hanisch -
Marko Mäkelä -
Martin Wache -
Norm Dressler -
Thomas Reufer -
VDR User