Hi,
First of all i want to thank Klaus for VDR. Vdr has been now "part of my life" for roughly 10 years, and i can't imagine myself changing it to anything else!
I have finally got time to migrate xineliboutput to softhddevice, but this has not been working 100% stable. I have had a couple of screen-freezes and screen-blackouts, and the only way to get this fixed was by restarting vdr. When using xineliboutput i have solved this by simply restarting my windowmanager (lightdm) by using an external command that reloads lightdm..
Is there a way that this could be done from vdr itself, eg by reloading the softhddevice-plugin with either an external command without stopping VDR?
Best Regards,
René
Rather than treating a symptom, why not try to figure out the root cause of your freezing and address it there?
On Thu, Feb 12, 2015 at 6:38 AM, René linuxtv@hertell.com wrote:
Hi,
First of all i want to thank Klaus for VDR. Vdr has been now "part of my life" for roughly 10 years, and i can't imagine myself changing it to anything else!
I have finally got time to migrate xineliboutput to softhddevice, but this has not been working 100% stable. I have had a couple of screen-freezes and screen-blackouts, and the only way to get this fixed was by restarting vdr. When using xineliboutput i have solved this by simply restarting my windowmanager (lightdm) by using an external command that reloads lightdm..
Is there a way that this could be done from vdr itself, eg by reloading the softhddevice-plugin with either an external command without stopping VDR?
Best Regards,
René
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 12.02.2015 17:27, VDR User wrote:
Rather than treating a symptom, why not try to figure out the root cause of your freezing and address it there?
That is of course the best solution, but i still would prefer an option to reload/restart a frontend instead of having to restart vdr..
René
Am 13.02.2015 um 00:02 schrieb René:
On 12.02.2015 17:27, VDR User wrote:
Rather than treating a symptom, why not try to figure out the root cause of your freezing and address it there?
That is of course the best solution, but i still would prefer an option to reload/restart a frontend instead of having to restart vdr..
René
start softhddevice suspended: ./vdr -P'softhddevice -g 1920x1080 -s' resume softhddevice: svdrpsend plug softhddevice RESU suspend again: svdrpsend plug softhddevice SUSP Jörg
On 13.02.2015 01:22, Joerg Riechardt wrote:
start softhddevice suspended: ./vdr -P'softhddevice -g 1920x1080 -s' resume softhddevice: svdrpsend plug softhddevice RESU suspend again: svdrpsend plug softhddevice SUSP Jörg
Thanks! I'll try this out. Hopefully a sequence of SUSP and RESU after a freeze will wake it up! :-)
Regards,
René
Am 13.02.2015 um 01:28 schrieb René:
On 13.02.2015 01:22, Joerg Riechardt wrote:
start softhddevice suspended: ./vdr -P'softhddevice -g 1920x1080 -s' resume softhddevice: svdrpsend plug softhddevice RESU suspend again: svdrpsend plug softhddevice SUSP Jörg
Thanks! I'll try this out. Hopefully a sequence of SUSP and RESU after a freeze will wake it up! :-)
As an alternative you can start softhddevice in detched mode (-D) and use the commands DETA/ATTA.
At yavdr we use this feature to start X and vdr in parallel and attach softhddevice when X is ready. And you can restart X when softhddevice is detached.
Difference: if softhddevice is suspended a keypress can resume it automatically. And if X isn't ready at this point you'll get an error (as far as I know).
Lars.
On 14.02.2015 19:53, VDR User wrote:
At yavdr we use this feature to start X and vdr in parallel and attach softhddevice when X is ready. And you can restart X when softhddevice is detached.
Do you happen to know approx. how much startup time is saved doing this?
Another case where one would want to use that way to start softhddevice is to be able to leave VDR running even when detaching softhddevice output to switch to xbmc/kodi or anything else, to be able to let VDR do recordings if necessary, or quickly switch back (of course, on a HTPC setup all from the remote control).
Regards, Lucian
14.02.2015 23:17, Lucian Muresan kirjutas:
On 14.02.2015 19:53, VDR User wrote:
At yavdr we use this feature to start X and vdr in parallel and attach softhddevice when X is ready. And you can restart X when softhddevice is detached.
Do you happen to know approx. how much startup time is saved doing this?
Another case where one would want to use that way to start softhddevice is to be able to leave VDR running even when detaching softhddevice output to switch to xbmc/kodi or anything else, to be able to let VDR do recordings if necessary, or quickly switch back (of course, on a HTPC setup all from the remote control).
Regards, Lucian
It's exactly case that I have.
A.
Am 14.02.2015 um 19:53 schrieb VDR User:
At yavdr we use this feature to start X and vdr in parallel and attach softhddevice when X is ready. And you can restart X when softhddevice is detached.
Do you happen to know approx. how much startup time is saved doing this?
We have no times for this isolated feature of starting X and vdr parallel, because we do more. We don't use lircd, but eventlircd, because eventlircd has not to wait until the remote devices are ready, so the vdr don't need to wait for them too. Many current dvb tuners need long time to get ready, sometimes because usb enumeration happens late, or firmware has to be loaded. For this Lars has invented the dynamite plugin that collects tuners when they are ready and gives them to the vdr. Other distributions have to wait with the vdr start till the last dvb tuner is ready. We don't wait for any of them. The vdr will show a picture when the first tuner comes ready. Of course it is very hardware related, but 10 seconds from bios post till live tv is possible. We had even some customized setups that did it in 6 seconds.
Gerald
!DSPAM:54dfe318514691998282038!
We have no times for this isolated feature of starting X and vdr parallel, because we do more. We don't use lircd, but eventlircd, because eventlircd has not to wait until the remote devices are ready, so the vdr don't need to wait for them too. Many current dvb tuners need long time to get ready, sometimes because usb enumeration happens late, or firmware has to be loaded. For this Lars has invented the dynamite plugin that collects tuners when they are ready and gives them to the vdr. Other distributions have to wait with the vdr start till the last dvb tuner is ready. We don't wait for any of them. The vdr will show a picture when the first tuner comes ready. Of course it is very hardware related, but 10 seconds from bios post till live tv is possible. We had even some customized setups that did it in 6 seconds.
Gerald
Hi Gerald,
This sounds great. What is the name of the distribution you are refering to?
Kind regards, Cedric
Am 15.02.2015 um 07:57 schrieb cedric.dewijs@telfort.nl:
We have no times for this isolated feature of starting X and vdr parallel, because we do more. We don't use lircd, but eventlircd, because eventlircd has not to wait until the remote devices are ready, so the vdr don't need to wait for them too. Many current dvb tuners need long time to get ready, sometimes because usb enumeration happens late, or firmware has to be loaded. For this Lars has invented the dynamite plugin that collects tuners when they are ready and gives them to the vdr. Other distributions have to wait with the vdr start till the last dvb tuner is ready. We don't wait for any of them. The vdr will show a picture when the first tuner comes ready. Of course it is very hardware related, but 10 seconds from bios post till live tv is possible. We had even some customized setups that did it in 6 seconds.
Gerald
Hi Gerald,
This sounds great. What is the name of the distribution you are refering to?
As he is the founder of yaVDR, it's yaVDR. :)
Lars.
On 13.02.2015 00:02, René wrote:
On 12.02.2015 17:27, VDR User wrote:
Rather than treating a symptom, why not try to figure out the root cause of your freezing and address it there?
That is of course the best solution, but i still would prefer an option to reload/restart a frontend instead of having to restart vdr..
Just for the record: as far as I see this, it's not a "frontend" that is hanging, but rather the *output device*. The term "frontend" in Linux DVB refers to the receiving devices, like /dev/dvb/adapter0/frontend0, where the application sets all the parameters necessary to receive a particular channel.
Klaus
Hi!
Am 02/12/2015 um 03:38 PM schrieb René:
[...] I have finally got time to migrate xineliboutput to softhddevice, but
Just for the curious: Why did you move from xineliboutput to softhddevice? Are there any major advantages?
From my experience the client-/server-setup (vdr-sxfe) of xineliboutput has the advantage, that I have a stable running VDR, even when I restart the output-device.
Regards, Stephan.
-
Arthur -
cedric.dewijs＠telfort.nl -
Gerald Dachs -
Joerg Riechardt -
Klaus Schmidinger -
Lars Hanisch -
Lucian Muresan -
René -
Stephan Loescher -
VDR User