On Sun, Dec 7, 2008 at 9:43 AM, Klaus Schmidinger <Klaus.Schmidinger at cadsoft.de http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr> wrote:
On 07.12.2008 18:40, gimli wrote:
/ Hi Klaus,
/>/ />/ just one question. Do you also use a budget system ? />/ If so, how do you watch TV with vdr 1.7.1 and later ;) />/ since xineliboutput is completly broken with it. / Currently I still have a FF DVB card for replaying, which, in the long run, will be replaced by an eHD card.
Klaus
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a €65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a €65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg!
which cpu do you have ? What about pictures quality on your TVset ? are you using hdmi ? so , did you test a lot of 1080i/1080p samples ? or only test samples from NVidia ?
That's NOT software decoding if you ask
it's GPU decoding :)
me. And now that hdmi audio finally works with nvidia it's just awesome.
ah, fine
I REALLY hope the xine guys will get this running soon.
+1
Btw, thanks to Klaus and the rest for all the work you put into this.
+1 too :)
Goga777 wrote:
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a €65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg!
which cpu do you have ? What about pictures quality on your TVset ? are you using hdmi ? so , did you test a lot of 1080i/1080p samples ? or only test samples from NVidia ?
This is with a 4850e but I'm sure a €20 LE-1150 would do this without a problem. An Intel could just allow digital video on Atom boards, that on a mini-ITX with nvidia 9300 would be ideal. I havn't tried a lot yet, just Apple trailers and that's not really a good test,I know. And there's still work to do on image quality but it's a great first attempt. But there's no deinterlacing that I know of yet. I'm using hdmi including audio on a 1360x768 LCD. /Magnus
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H
Why all this eHD-bashing? Just because a *commercial* company already made a complete HDTV-vdr-solution more than 18 months ago that the vdr-community hasn't achieved until now?
Of course the eHD won't live forever, probably not half as long as the FF-card, but it solved an imminent issue at that time and it allowed to run vdr and HDTV on it.
I also favour decoding in the graphics card instead of dedicated HW, but please make a reality check: For Linux, this option is now available for 4 weeks or so...
BTW: The HDTV/h264-capability is in no way related to the eHD, so it simply cannot drive vdr in the wrong direction. If you look at the stuff that the reelvdr already has in its core for TS/HDTV/h264-handling you will see that there is ZERO dependency on the eHD. The eHD-reelvant code is just an output-plugin similar to the softdevice-plugin.
The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made?
On Tue, Dec 9, 2008 at 11:48 AM, Georg Acher acher@in.tum.de wrote:
The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made?
There are many thousands of reelvdr users? That's news to me but ok.
On Tue, Dec 09, 2008 at 12:46:21PM -0800, VDR User wrote:
On Tue, Dec 9, 2008 at 11:48 AM, Georg Acher acher@in.tum.de wrote:
The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made?
There are many thousands of reelvdr users? That's news to me but ok.
I don't know the exact numbers, but the Reelbox Lite was about 4-5k. Only one batch of PCBs was produced because later the prices for the used chips increased dramatically. So RMM was without a product for nearly 18 months...
The Avantgarde is definitely already way beyond these figures.
Georg Acher wrote:
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H
Why all this eHD-bashing? Just because a *commercial* company already made a complete HDTV-vdr-solution more than 18 months ago that the vdr-community hasn't achieved until now?
Of course the eHD won't live forever, probably not half as long as the FF-card, but it solved an imminent issue at that time and it allowed to run vdr and HDTV on it.
I also favour decoding in the graphics card instead of dedicated HW, but please make a reality check: For Linux, this option is now available for 4 weeks or so...
BTW: The HDTV/h264-capability is in no way related to the eHD, so it simply cannot drive vdr in the wrong direction. If you look at the stuff that the reelvdr already has in its core for TS/HDTV/h264-handling you will see that there is ZERO dependency on the eHD. The eHD-reelvant code is just an output-plugin similar to the softdevice-plugin.
The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made?
I'm sorry if you think I was "bashing" the eHD card or RMM, that was not my intention. What I meant was that I hope Klaus doesn't buy one because I think that would keep him in the "ff-card/one computer/one user"-thinking longer. If he switched to using xinelib/ffmpeg I think we would see a "separated vdr-backend with multiple frontends capability"-scenario a lot sooner, don't you? Or is it just me who sometimes like to look at some other show than my wife or kids, even though I love to be with them most of the time? /Magnus
On 09.12.2008 21:47, Magnus Hörlin wrote:
...
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H
...
I'm sorry if you think I was "bashing" the eHD card or RMM, that was not my intention. What I meant was that I hope Klaus doesn't buy one because
I already have one ;-)
I think that would keep him in the "ff-card/one computer/one user"-thinking longer. If he switched to using xinelib/ffmpeg I think we would see a "separated vdr-backend with multiple frontends capability"-scenario a lot sooner, don't you?
My VDR is one machine with several DVB devices and hardware replay. As long as there is a way of having a good hardware replay, why shouldn't I use it?
Why would software replay in my VDR change anyting regarding "separated vdr-backend with multiple frontends capability"?
Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases...
Klaus
Klaus Schmidinger wrote:
On 09.12.2008 21:47, Magnus Hörlin wrote:
...
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H
...
I'm sorry if you think I was "bashing" the eHD card or RMM, that was not my intention. What I meant was that I hope Klaus doesn't buy one because
I already have one ;-)
Ok, I missed that.
I think that would keep him in the "ff-card/one computer/one user"-thinking longer. If he switched to using xinelib/ffmpeg I think we would see a "separated vdr-backend with multiple frontends capability"-scenario a lot sooner, don't you?
My VDR is one machine with several DVB devices and hardware replay. As long as there is a way of having a good hardware replay, why shouldn't I use it?
My opinion as a hardware design engineer is that when my cpu is 97% idle displaying 1080p video, it is hardware replay. And the GPU is already there for the majority of the vdr users, so why not focus on that?
Why would software replay in my VDR change anyting regarding "separated vdr-backend with multiple frontends capability"?
My guess was that if xinelib was your "native" vdr frontend, perhaps you would try running it on your laptop or desktop machine or whatever, and eventually see that there's room for improvement when running multiple frontends.
Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases...
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
That's just my point, you havn't tried it for the above mentioned reasons..... I use streamdev and multiple vdr instances myself, but it's not perfect. I really hope you don't take any offence by my posts, I'm a huge fan. /Magnus
On 09.12.2008 23:04, Magnus Hörlin wrote:
Klaus Schmidinger wrote:
On 09.12.2008 21:47, Magnus Hörlin wrote:
...
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H
...
I'm sorry if you think I was "bashing" the eHD card or RMM, that was not my intention. What I meant was that I hope Klaus doesn't buy one because
I already have one ;-)
Ok, I missed that.
I think that would keep him in the "ff-card/one computer/one user"-thinking longer. If he switched to using xinelib/ffmpeg I think we would see a "separated vdr-backend with multiple frontends capability"-scenario a lot sooner, don't you?
My VDR is one machine with several DVB devices and hardware replay. As long as there is a way of having a good hardware replay, why shouldn't I use it?
My opinion as a hardware design engineer is that when my cpu is 97% idle displaying 1080p video, it is hardware replay. And the GPU is already there for the majority of the vdr users, so why not focus on that?
Well, tell that to people writing plugins for such output devices. I don't see where *I* would be involved there?! I want an easy to use hardware output device, and so far the FF DVB cards served me just fine. The next step in *my* VDR will be an eHD card (as I already have one). Others may use whatever output device they prefer. That's why cDevice is a virtual class and allows implementing any kind of output device ;-)
Why would software replay in my VDR change anyting regarding "separated vdr-backend with multiple frontends capability"?
My guess was that if xinelib was your "native" vdr frontend, perhaps you would try running it on your laptop or desktop machine or whatever, and eventually see that there's room for improvement when running multiple frontends.
Maybe I'll even get there one day - but it's no immediate need for me. Sorry for being a little "selfish" here, but I always made it clear that VDR to me is a plain, simple digital receiver and video recorder. Nothing fancy, no bells and whistles, just recording and replaying video broadcasts.
Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases...
That's just my point, you havn't tried it for the above mentioned reasons..... I use streamdev and multiple vdr instances myself, but it's not perfect. I really hope you don't take any offence by my posts, I'm a huge fan.
I haven't seen anything offensive in your posts ;-)
Klaus
Klaus Schmidinger wrote:
Well, tell that to people writing plugins for such output devices. I don't see where *I* would be involved there?!
Are there enough interfaces to be able to read the and control the OSD for including them seamlessly it into a different front-end? I don´t think that SVDRP and interpreting the returned data is the best way to go. And what about the limitation on one OSD per VDR? I think, these are the real limitations - currently users of media center UIs are exiting them and start xinelib for using VDR and visa verse. A better separation of "back-end" and "front-end" could IMHO solve the problem and end the discussion about hardware related support. Because with a clean and some kind of more standardized interface (which also transmits OSD related information), you could write every "output device connector/plug-in" that you can think and be compatible to more front-ends or devices then before. Even an "evil" Windows front-end with VDR running on Windows (with the help of something like colinux or a VM) would be possible. Currently, xinelib (with original OSD) uses a different protocol than the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in (with OSD tranfered with some kind of VNC IIRC) which also works different from the streamdev approach (without OSD) that is used for hardware streaming clients that use oxyl etc.
Unfortunately, I am just a user, not a developer though I am at least able to read and modify simple C and script code ;) - it has been a long time since I was student and was able/had the time to code little projects...
With kind regards
Joerg Knitter
Jörg Knitter a écrit :
Klaus Schmidinger wrote:
Well, tell that to people writing plugins for such output devices. I don't see where *I* would be involved there?!
Are there enough interfaces to be able to read the and control the OSD for including them seamlessly it into a different front-end? I don´t think that SVDRP and interpreting the returned data is the best way to go. And what about the limitation on one OSD per VDR? I think, these are the real limitations - currently users of media center UIs are exiting them and start xinelib for using VDR and visa verse. A better separation of "back-end" and "front-end" could IMHO solve the problem and end the discussion about hardware related support. Because with a clean and some kind of more standardized interface (which also transmits OSD related information), you could write every "output device connector/plug-in" that you can think and be compatible to more front-ends or devices then before. Even an "evil" Windows front-end with VDR running on Windows (with the help of something like colinux or a VM) would be possible. Currently, xinelib (with original OSD) uses a different protocol than the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in (with OSD tranfered with some kind of VNC IIRC) which also works different from the streamdev approach (without OSD) that is used for hardware streaming clients that use oxyl etc.
Unfortunately, I am just a user, not a developer though I am at least able to read and modify simple C and script code ;) - it has been a long time since I was student and was able/had the time to code little projects...
I second that completely. IMHO, the core VDR should move toward a multiple OSD capability. Maybe the network separation between the back-end and the front-end could just be a compilation setting (add a RPC layer at the correct place, as a compilation option : no layer = current standalone setup; network layer = VDR server + VDR clients). This should provide a clean way to separate the responsibilities between the back-end and the front-ends. The rest is a matter of plug-ins and not over Klaus shoulders.
I agree that the hardware side of this is just the visible part (and a good flame-war starter). The plugin architecture allows many things, which is good. The limits of the core makes it hard to create a network-happy VDR system (not a VDR machine, but a system of multiple machines), which is the root of many incompatible and incomplete plugins, solving all part of the problem (xineliboutput, remoteosd, dummydevice, epgsync, remotetimers, etc.)
I just recently started using streamdev, for a bare EPIA ML6000 client (diskless, no DVB device, just mobo + RAM + network). I think it's a good (and cheap, silent, power-efficient) starting point for a network-based STB. It's not perfect, but most of the imperfections come from the plugins that must be added and configured, each separately, to achieve a good VDR network STB.
It is already possible to have disks array, DVB devices, and all the cables down in the closet, and as many clients we want behind each TV set, with only a CAT5 cable and an IR sensor. That's just difficult. Moving existing plugin code into the VDR core, and getting some out of the core, into plugin, would do a lot in the "right" direction.
I trust Klaus to eventually get to it, and the community to provide good plugins, providing a tremendous network STB system. I'm not impatient at all, I know this will happen. The more time it take, the better will be the solution, the longer it will stay.
I look at how my neighbours watch TV : DVB-S converted to an analog signal recorded on a crappy VCR, sending wireless scratchy analog to an LCD TV (which was really the top 5 years ago), one tape at a time, no timeshifting, etc. ...and I'm really happy with VDR.
It is already possible to have disks array, DVB devices, and all the cables down in the closet, and as many clients we want behind each TV set, with only a CAT5 cable and an IR sensor. That's just difficult. Moving existing plugin code into the VDR core, and getting some out of the core, into plugin, would do a lot in the "right" direction.
I can say I've seen many people move away from VDR because it doesn't provide a good solution to this. After years of using standalone VDR boxes, I too would love if we had the option to use a networked VDR with each client being exactly as you described... Diskless, and only with ethernet cable + IR sensor, and each with an own OSD to control his VDR thread.
I trust Klaus to eventually get to it, and the community to provide good plugins, providing a tremendous network STB system. I'm not impatient at all, I know this will happen. The more time it take, the better will be the solution, the longer it will stay.
The need/want is there for this but I have to disagree about trusting Klaus will get to it. I apologize if I'm incorrect but as far as I know he has no plans to make such mods and recommends you use something else if that's what you want. I think Klaus openly admits that he's mostly concerned with his own needs and intended that VDR be a standalone system. Which is fine, as it's creator he has every right to stick to that. I personally see so much potential in what VDR could become but whether or not it ever gets there is uncertain in my opinion. As a long time user who would love nothing more then to be able to stay with VDR, I hope that it will evolve along with the times/needs.
Although talking about such things seems almost like day-dreaming, one thing that we finally are getting is support for TS recordings and h264 support which I think is a big step in the right direction so to that I say Viva La Klaus! ;)
On 12.12.2008 18:06, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't provide a good solution to this. After years of using standalone VDR boxes, I too would love if we had the option to use a networked VDR with each client being exactly as you described... Diskless, and only with ethernet cable + IR sensor, and each with an own OSD to control his VDR thread.
Hmmm, sounds just like what I have in my bedroom. Ok, it has a local disk for convenience, but no own receiver and no locally stored recordings. It could easily run from an USB stick or do network boot if I want. Oh, and the 'second remote frontend' is actually a complete VDR using streamdev.
I really don't get the point why it is necessary to totally rewrite VDR core to support multiple frontends (surely loosing compatibility to almost all plugins), when it will at the end just start one thread per frontend, while we can already start one VDR instance per frontend right now.
Even better: If one frontend crashes (well, it doesn't, but lets assume), the core VDR just runs on and none of the other frontends crashes too. Cool feature, or?
If you're not happy with using streamdev to connect several VDR instances, wouldn't it be the better way to improve streamdev to meet the needs instead of starting all over again? VDR remote frontends would need a streamdev-like interface anyway.
Cheers,
Udo
Udo Richter a écrit :
On 12.12.2008 18:06, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't provide a good solution to this. After years of using standalone VDR boxes, I too would love if we had the option to use a networked VDR with each client being exactly as you described... Diskless, and only with ethernet cable + IR sensor, and each with an own OSD to control his VDR thread.
Hmmm, sounds just like what I have in my bedroom. Ok, it has a local disk for convenience, but no own receiver and no locally stored recordings. It could easily run from an USB stick or do network boot if I want. Oh, and the 'second remote frontend' is actually a complete VDR using streamdev.
I really don't get the point why it is necessary to totally rewrite VDR core to support multiple frontends (surely loosing compatibility to almost all plugins), when it will at the end just start one thread per frontend, while we can already start one VDR instance per frontend right now.
Even better: If one frontend crashes (well, it doesn't, but lets assume), the core VDR just runs on and none of the other frontends crashes too. Cool feature, or?
If you're not happy with using streamdev to connect several VDR instances, wouldn't it be the better way to improve streamdev to meet the needs instead of starting all over again? VDR remote frontends would need a streamdev-like interface anyway.
In my opinion, the client and server are both full VDR, which just happen to use one part of the whole functionnality.
I'm just talking about a split line drawn in the core VDR. Maybe like the plugin interface is a split between what's in the core and what is not, there could be an internal network interface that splits what's in the front-end and what's in the back-end.
The problems that come to mind in typical current multiple VDR are : * DVB device handling is running even if there is no actual DVB device (OK, this is not a problem in practice, except for device numbers) * EPG data is not shared between VDR instances : the one holding the DVB devices could "distribute" the contents upon request (streamdev does nearly this) * recording list is also not shared, even though NFS does the actual sharing of files : if one VDR starts a new recording, the other ones won't see it until "some time", or until .update is touched ; if one VDR removes a recording that another one is recording, I'm not sure about the result (maybe a few GB lost in a strangely named directory ?) * schedules are not executed on the VDR instance holding the DVB devices, resulting in double network transfert, instead of none at all * if 2 VDRs record the same program at the same time, it seems to a be a big problem... If using a slightly different EPG data, this result in 2 recordings with different times, and if using the exact same EPG, this result in something weird and maybe unusable (say, same station, same EPG, one via DVB-S, the other one via DVB-T, two different streams in one file...)
Again, I trust Klaus and the collective creativity to come with a clean solution, some time. In the meantime, the current solution based on various plugins is OK for me. I just have to remind my wife that she can't do "this" or "that" from time to time ;-) Not that it's a problem for her. Not that it's difficult for me to see why.
(getting back to solder this stupid IR sensor which doesn't want to send anything to LIRC)
On 12.12.2008 23:23, Nicolas Huillard wrote:
The problems that come to mind in typical current multiple VDR are :
- DVB device handling is running even if there is no actual DVB device
(OK, this is not a problem in practice, except for device numbers)
When there are no DVB devices available at start, no overhead will be launched anyway. And if you explicitly don't want to use local DVB devices, you can say so on command line.
And if DVB support really moves into a plugin, as plans currently seem to be, then this will be solved anyway.
- EPG data is not shared between VDR instances : the one holding the DVB
devices could "distribute" the contents upon request (streamdev does nearly this)
My clients do get EPG, worked right out of the box.
- recording list is also not shared, even though NFS does the actual
sharing of files : if one VDR starts a new recording, the other ones won't see it until "some time", or until .update is touched ; if one VDR removes a recording that another one is recording, I'm not sure about the result (maybe a few GB lost in a strangely named directory ?)
There's a TouchUpdate() in cRecordings::AddByName and cRecordings::DelByName, that are probably there to do exactly what you request. Maybe there are some remaining bugs that need to be found.
- schedules are not executed on the VDR instance holding the DVB
devices, resulting in double network transfert, instead of none at all
Agreed. Solutions like RemoteOSD and RemoteTiemrs are merely workarounds. A nice solution to this integrated into VDR would improve things a lot here.
<brainstorming> Another parameter for every timer would be a nice solution: "Record locally" or "Record remotely" - VDR would have to connect to a remote VDR via SVDRP to read and write these timers.
- if 2 VDRs record the same program at the same time, it seems to a be a
big problem... If using a slightly different EPG data, this result in 2 recordings with different times, and if using the exact same EPG, this result in something weird and maybe unusable (say, same station, same EPG, one via DVB-S, the other one via DVB-T, two different streams in one file...)
This would be a lot better with a client-server timer structure. And in the end, I'm pretty sure you don't need two VDR instances to record two different programs into the same folder, or?
Cheers,
Udo
Udo Richter a écrit :
- if 2 VDRs record the same program at the same time, it seems to a be a
big problem... If using a slightly different EPG data, this result in 2 recordings with different times, and if using the exact same EPG, this result in something weird and maybe unusable (say, same station, same EPG, one via DVB-S, the other one via DVB-T, two different streams in one file...)
This would be a lot better with a client-server timer structure. And in the end, I'm pretty sure you don't need two VDR instances to record two different programs into the same folder, or?
...this is a human error, but AFAIK nothing prevents it...
Other point : previous emails talk about various possibilities about DVB device "location". My ideal setup would be : * all DVB devices in a single headless always-on server * all clients diskless, using an NFS share
This avoids to raise problems like DVB devices spread around on clients, all with different capabilities, etc. Which could be a real nightmare WRT selecting the proper (powered on) device for recording/liveview, etc... I understand that VDR needs a plugin to solve issues like various DVB-S devices not pointed at the same satellite. Distributing this problem in a client/server setup seems arbitrarily complex to me.
(I currently have DVB devices partly spread around, and I don't want VDR or any plugin to solve this issue, as I can just move hardware around) (I also think that VDR is the only STB that can record many channels regardless of the number of tuners : every other commercial STB I know of can record one channel per tuner, and does not even try to suggest that it could be possible to record a second one without a second tuner. The bar is fairly low here, and VDR works much better than normal people expect)
Cheers,
Nicolas Huillard wrote:
Udo Richter a écrit :
- if 2 VDRs record the same program at the same time, it seems to a be a
big problem... If using a slightly different EPG data, this result in 2 recordings with different times, and if using the exact same EPG, this result in something weird and maybe unusable (say, same station, same EPG, one via DVB-S, the other one via DVB-T, two different streams in one file...)
This would be a lot better with a client-server timer structure. And in the end, I'm pretty sure you don't need two VDR instances to record two different programs into the same folder, or?
...this is a human error, but AFAIK nothing prevents it...
Other point : previous emails talk about various possibilities about DVB device "location". My ideal setup would be :
- all DVB devices in a single headless always-on server
- all clients diskless, using an NFS share
This would be ideal solution for me as well!
Br, Pasi
-----Ursprungligt meddelande----- Från: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] För Pasi Juppo Skickat: den 15 december 2008 16:31 Till: VDR Mailing List Ämne: Re: [vdr] VDR with S2API (update)
Other point : previous emails talk about various possibilities about DVB device "location". My ideal setup would be :
- all DVB devices in a single headless always-on server
- all clients diskless, using an NFS share
This would be ideal solution for me as well!
Br, Pasi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
That's how I have always used VDR, one server with seven DVB-S/S2/T cards and three diskless clients plus one laptop. Currently I run just one vdr instance on the server and one instance on each client, except the "master" client that connects via xineliboutput to the server's vdr. /Magnus H
On Sat, 13 Dec 2008 12:31:05 +0100, Udo Richter wrote
Agreed. Solutions like RemoteOSD and RemoteTiemrs are merely workarounds. A nice solution to this integrated into VDR would improve things a lot here.
Just curious: What are you missing?
<brainstorming> Another parameter for every timer would be a nice solution: "Record locally" or "Record remotely" - VDR would have to connect to a remote VDR via SVDRP to read and write these timers.
Isn't that exactly what remotetimers-plugin already provides?
Cheers, Frank
Udo Richter udo_richter@gmx.de wrote:
I really don't get the point why it is necessary to totally rewrite VDR core to support multiple frontends (surely loosing compatibility to almost all plugins), when it will at the end just start one thread per frontend, while we can already start one VDR instance per frontend right now.
at least the /video directory that is shared across multiple vdr instances that know nothing about each other is a single race-condition on its own.
vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up.
clemens
Clemens Kirchgatterer wrote:
Udo Richter udo_richter@gmx.de wrote:
I really don't get the point why it is necessary to totally rewrite VDR core to support multiple frontends (surely loosing compatibility to almost all plugins), when it will at the end just start one thread per frontend, while we can already start one VDR instance per frontend right now.
at least the /video directory that is shared across multiple vdr instances that know nothing about each other is a single race-condition on its own.
vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up.
clemens
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
You're right. I would like a setup where there's one master vdr that does all the recording and has access to the dvb cards. The slaves can start and watch recordings on the master vdr, and watch live tv of course. Then I'd be happy. Streamdev is almost there, but not all the way. I would also like to export videodir read-only but my problem is vdr won't start on a read-only videodir. /Magnus H
Clemens Kirchgatterer wrote:
vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up.
Not giant system, but some experiences: I have one server running three instances of vdr. Vdr #2 and #3 are connected by streamdev to vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1. Three client PCs run just vdr-sxfe as explained in xinelibout's README file.
Pros - Easy to maintain
Cons - Recordings are only loosely synchronized trough a script that touches .update file when recording is started. - Deletion synchronization is not solved. - Channels are synchronized loosely by cron job only every night when clients #2 and #3 can be killed "safely" - The biggest annoyance: Possible to pause live TV only in vdr #1
I would be really happy to see improvement in vdr client-server architecture. AFAIK Mythtv does this nicely. I just have been too lazy to set up a totally new system while the current one is actively used.
BR, Seppo
Seppo Ingalsuo seppo.ingalsuo@iki.fi wrote:
vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up.
Not giant system, but some experiences: I have one server running three instances of vdr. Vdr #2 and #3 are connected by streamdev to vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1.
yes, intelligent timer migration between vdr instances is a not trivial task. when a timer is to be fired, you have to ask all vdr instances its timer list and move the timer to the most suitable instance. taking into account recordings on the same transponder to not waste dvb devices. the same gues for finding a free dvb device for life-view.
best regards ... clemens
On Sun, 14 Dec 2008 09:42:40 +0100, Clemens Kirchgatterer wrote
Seppo Ingalsuo seppo.ingalsuo@iki.fi wrote:
vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up.
Not giant system, but some experiences: I have one server running three instances of vdr. Vdr #2 and #3 are connected by streamdev to vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1.
yes, intelligent timer migration between vdr instances is a not trivial task. when a timer is to be fired, you have to ask all vdr instances its timer list and move the timer to the most suitable instance. taking into account recordings on the same transponder to not waste dvb devices. the same gues for finding a free dvb device for life-view.
You're no longer talking about client-server here. What you have in mind is peer-to-peer. Streamdev et al. haven't been designed for this. I never looked at videgor, but AFAIK it was a peer-to-peer aproach.
Cheers, Frank
"Frank Schmirler" vdr@schmirler.de wrote:
yes, intelligent timer migration between vdr instances is a not trivial task. when a timer is to be fired, you have to ask all vdr instances its timer list and move the timer to the most suitable instance. taking into account recordings on the same transponder to not waste dvb devices. the same gues for finding a free dvb device for life-view.
You're no longer talking about client-server here. What you have in mind is peer-to-peer. Streamdev et al. haven't been designed for this. I never looked at videgor, but AFAIK it was a peer-to-peer aproach.
exactly what i was talking about. at the moment a multi vdr setup is a peer to peer setup and thus makes timer migration complex. or you do it by hand with the help of remote timers plugin and the like. but this lacks the DVB sharing across vdr instances.
clemens
Hi,
Seppo Ingalsuo wrote:
Clemens Kirchgatterer wrote:
vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up.
Not giant system, but some experiences: I have one server running three instances of vdr. Vdr #2 and #3 are connected by streamdev to vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1. Three client PCs run just vdr-sxfe as explained in xinelibout's README file.
My experience with a vdr#1 on a box with a dvb-s FF and a dvb-t card. And a vdr#2 connected via streamdev.
It works, but it's really an hack/mess and lack lot's of features :
- on my configuration the recording only work on vdr#1. on vdr#2 svdrp should be used to control recording and ftp to read them (with a video player) - on my configuration some dvb-s and dvb-t channels are the same. If vdr#1 is watching a channel on dvb-s (that is also on dvb-t), but vdr#2 want to use another transponder on dvb-s, the switch should be done by hand. - I have got issue for some channels that are encrypted at some hours and free at other hours - IRRC nothing that stop the master (vdr#1) to powerdown (even if vdr#2 is in use). Nothing that allow vdr#2 to powerdown vdr#1 if nobody watch TV. - no channel sync
I wanted to give a try to mythtv (or freevo) but neither of them doesn't seem to support output on FF card.
Matthieu
On 14.12.2008 11:23, matthieu castet wrote:
- on my configuration the recording only work on vdr#1. on vdr#2 svdrp
should be used to control recording and ftp to read them (with a video player)
I never tried to record on the streaming client, but beside the fact that video will go unnecessarily twice across network, it should work fine. Playing back recordings from the 'master' VDR by nfs share works perfectly.
- on my configuration some dvb-s and dvb-t channels are the same. If
vdr#1 is watching a channel on dvb-s (that is also on dvb-t), but vdr#2 want to use another transponder on dvb-s, the switch should be done by hand.
Its an old discussion whether two channels with same program should be treated as one. Sometimes, the schedule may be different at certain day times, or quality may be lower as in DVB-T case.
- IRRC nothing that stop the master (vdr#1) to powerdown (even if vdr#2
is in use). Nothing that allow vdr#2 to powerdown vdr#1 if nobody watch TV.
My master VDR automatically powers down 5 minutes after the slave VDR disconnects, provide it is idle. If it is not, I fire a power key hit via SVDRP. Works perfectly. Especially the master never shuts down while the slave is running. To wake the master from the slave, I fire a Wake-on-LAN packet. All done via Commands menu.
- no channel sync
This would make an excellent addition to streamdev.
Cheers,
Udo
On Sun, 14 Dec 2008 16:42:21 +0100, Udo Richter wrote
- no channel sync
This would make an excellent addition to streamdev.
Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should stick to what it was meant for: streaming. Remember 4 years ago: Remotetimers feature was part of streamdev by that time. The menu classes in VDR 1.3 started to change frequently and noone kept up with the necessary changes to streamdev.
Personally I never missed a channel sync feature. The major channels rarely ever change. Futhermore streamdev and related plugins all use the channel ID, so no need to have the same channel numbers on client and server. Also channel updates and link channels work right out of the box.
Cheers, Frank
On 15.12.2008 11:06, Frank Schmirler wrote:
- no channel sync
This would make an excellent addition to streamdev.
Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should stick to what it was meant for: streaming.
Streamdev is a receiving device within VDR, and VDR can do automatic channel updates. So I think that its part of the job to provide channel information, just like providing epg data. And for channels with changing language IDs and similar this is even useful.
However, using unused devices for epg and channel scan won't be a solution here, as any server will soon run out of devices if every client does scanning on his own.
Cheers,
Udo
On Sat, 20 Dec 2008 20:31:33 +0100, Udo Richter wrote
On 15.12.2008 11:06, Frank Schmirler wrote:
- no channel sync
This would make an excellent addition to streamdev.
Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should stick to what it was meant for: streaming.
Streamdev is a receiving device within VDR, and VDR can do automatic channel updates. So I think that its part of the job to provide channel information, just like providing epg data. And for channels with changing language IDs and similar this is even useful.
It seems that we have a different understanding of the term "channel sync". Streamdev-0.3.4 has the capabilities you're talking about. What I had in mind was merging or replacing the client's with the server's channels list.
Cheers, Frank
On 20.12.2008 23:37, Frank Schmirler wrote:
It seems that we have a different understanding of the term "channel sync". Streamdev-0.3.4 has the capabilities you're talking about. What I had in mind was merging or replacing the client's with the server's channels list.
One thing is updating the channels and adding new ones (either based on source or based on server channel list), another one is reordering channels like on the server.
Channel update never worked for me. Guess its time to update then. ;)
Cheers,
Udo
On Sat, 13 Dec 2008 18:52:52 +0200, Seppo Ingalsuo wrote
- The biggest annoyance: Possible to pause live TV only in vdr #1
Have you tried with the VDR patch from remotetimers-0.1.0? I never took the time to test it with timersync-plugin, but I'd be interested to see if instant recordings and pause live TV works with it, too.
Cheers, Frank
Frank Schmirler wrote:
On Sat, 13 Dec 2008 18:52:52 +0200, Seppo Ingalsuo wrote
- The biggest annoyance: Possible to pause live TV only in vdr #1
Have you tried with the VDR patch from remotetimers-0.1.0? I never took the time to test it with timersync-plugin, but I'd be interested to see if instant recordings and pause live TV works with it, too.
I didn't know about the patch. It would be nice to get pause to work!
I wonder if it solves the problems when the channels are not perfectly in sync? I have a manually sorted DVB-T channels section but my autosort handled huge amount of DVB-S channels are usually bit different in vdr instances due to frequent updates. I think timersync works only when the channel numbers match.
Seppo
Cheers, Frank
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Mon, 15 Dec 2008 21:50:45 +0200, Seppo Ingalsuo wrote
I wonder if it solves the problems when the channels are not perfectly in sync? I have a manually sorted DVB-T channels section but my autosort handled huge amount of DVB-S channels are usually bit different in vdr instances due to frequent updates. I think timersync works only when the channel numbers match.
A quick glance at the timersync code reveals that indeed it uses channel numbers and not channel ids. I don't know if this is on purpose or not. If you want to give it a try: Edit timersync.c and simply replace every occurrence of "ToText()" by "ToText(true)" (about 14 times).
Regards, Frank
Hi there. Does anyone know if there has been any progress with xineliboutput and 1.7.1 or 1.7.2? And what about streamdev-server and streamdev-client? Do they work? I have just switched to s2api on 1.7.0 and it (sort of) works, but I would like to give feedback on 1.7.2. However I need xineliboutput and streamdev so I guess I have to wait, or? Thanks, /Magnus H
Hi, Streamdev-server from cvs seems to work, no idea about xineliboutput! HTH. Halim
Hi, On Fr, Dez 12, 2008 at 09:06:02 -0800, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't provide a good solution to this. After years of using standalone VDR boxes, I too would love if we had the option to use a networked VDR with each client being exactly as you described... Diskless, and only with ethernet cable + IR sensor, and each with an own OSD to control his VDR thread.
This would add more complexity to vdr and make it unstable. BTW. VDR is a video disk recorder not a media center?? I don't know an other multimedia project like vdr wich works stable like vdr.
Maybe those people who wants such a networking capable vdr should fork it and implement the needed features?
Please stop writing Many people move away from vdr etc. if they have a working solution it is ok. In this case there is an alternative to vdr and Klaus doesn't need to implement such features. Just my two cents. halim
On Fri, Dec 12, 2008 at 12:30 PM, Halim Sahin halim.sahin@t-online.de wrote:
This would add more complexity to vdr and make it unstable. BTW. VDR is a video disk recorder not a media center?? I don't know an other multimedia project like vdr wich works stable like vdr.
Why would you assume VDR would become unstable? You must not have much confidence in Klaus and the others who contribute code to VDR! I think these people are perfectly capable of doing a great job with whatever changes/enhancements the future holds. Also, yes VDR stands for Video Disk Recorder but that's irrelevant. Have you ever considered that during VDR's conception and early development 8-9 years ago that pc media center's wern't really viable? Times have changed, why do you think there's emphasis on integration these days? I'll give you an example... 8-9 years ago having a usb port on a television was silly but now many models have one or something similar so people can easily display their digital pictures. Change is nothing to be scared of and can yield great new advantages.
Maybe those people who wants such a networking capable vdr should fork it and implement the needed features?
Possibly. However, I could be wrong but didn't Klaus recently say if anyone forks VDR, he would stop developing it? And it isn't as if there's a huge pool of coders working on VDR to begin with.
Please stop writing Many people move away from vdr etc. if they have a working solution it is ok. In this case there is an alternative to vdr and Klaus doesn't need to implement such features.
I don't see why we shouldn't be allowed to speak the truth. Also, I think it's pretty poor thinking to say if an alternative exists then there's no reason to implement more features. Almost every person I know who switched to MythTV wishes they never had to and would come back to VDR in a heartbeat if it offered the big features. I'm not talking about eye candy and so on, I don't know anyone who switched for that reason so please don't bother mentioning it.
For all of us who hope VDR might become more then it is now and meet the needs of the growing number of 'media center' users, our opinions are every bit as valid as yours not wanting such progression.
Don't put down peoples passion for VDR. It should be taken as a compliment!
On 13.12.2008 00:04, VDR User wrote:
Maybe those people who wants such a networking capable vdr should fork it and implement the needed features?
Possibly. However, I could be wrong but didn't Klaus recently say if anyone forks VDR, he would stop developing it? And it isn't as if there's a huge pool of coders working on VDR to begin with.
There have been forks before, especially for commercial projects. I guess what Klaus' meant was that a major community-driven fork that takes over the 'best vdr ever' lead position would mean the end to his 'second best vdr ever' project and to his major development role.
Cheers,
Udo
Magnus Hörlin schrieb:
My VDR is one machine with several DVB devices and hardware replay. As long as there is a way of having a good hardware replay, why shouldn't I use it?
My opinion as a hardware design engineer is that when my cpu is 97% idle displaying 1080p video, it is hardware replay. And the GPU is already there for the majority of the vdr users, so why not focus on that?
Sure? I haven't a GPU in my VDR for years. Only a FF-Card and a throttled CPU.
Isn't PAL enough for everybody? *duckandcover*
On Tuesday 09 December 2008 22:44:07 Stefan Hußfeldt wrote:
Magnus Hörlin schrieb:
My VDR is one machine with several DVB devices and hardware replay. As long as there is a way of having a good hardware replay, why shouldn't I use it?
My opinion as a hardware design engineer is that when my cpu is 97% idle displaying 1080p video, it is hardware replay. And the GPU is already there for the majority of the vdr users, so why not focus on that?
Sure? I haven't a GPU in my VDR for years. Only a FF-Card and a throttled CPU.
Isn't PAL enough for everybody? *duckandcover*
and me. I don't have room for any more than DVB-T and FF in my VDR barebone system
Andy
Isn't PAL enough for everybody? *duckandcover*
and me. I don't have room for any more than DVB-T and FF in my VDR barebone system
And many more. I've installed vdr for > 50 persons - most of these are still happy with an old P3 or Celeron ... In Germany there's definitely no run for HDTV (No wonder because none of the favourite stations are using it).
On Tue, 09 Dec 2008 22:39:04 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases...
Am I right in thinking you can't use the OSD with streamdev, the only control you've got is using the URI to select a channel? I think having a global OSD and control interface is quite limiting; if, for example, each xineliboutput client could have its own OSD and control channel it would be a big improvement, but I realise it would need a major change to the API etc.
Klaus Schmidinger wrote:
Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases...
I've seen multi client streamdev users run multiple vdr daemons in server machine, one for each client. Maybe this could be improved to allow multiple instances of plugin run in one daemon?
On Wed, 10 Dec 2008 11:59:47 +0200, Pertti Kosunen wrote
Klaus Schmidinger wrote:
Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases...
I've seen multi client streamdev users run multiple vdr daemons in server machine, one for each client. Maybe this could be improved to allow multiple instances of plugin run in one daemon?
A single streamdev-server instance can be used by multiple clients. No need for multiple instances here.
The setup you are talking about addresses the problem that you can't have independent clients with xineliboutput: There's one VDR instance with streamdev-server controling the DVB cars. Then for each client, there's a VDR instance with xineliboutput and streamdev-client.
Regards, Frank
On Tue, Dec 9, 2008 at 7:48 PM, Georg Acher acher@in.tum.de wrote:
Why all this eHD-bashing? Just because a *commercial* company already made a complete HDTV-vdr-solution more than 18 months ago that the vdr-community hasn't achieved until now?
Of course the eHD won't live forever, probably not half as long as the FF-card, but it solved an imminent issue at that time and it allowed to run vdr and HDTV on it.
The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made?
Georg,
I have bought an eHD for my vanilla VDR, possibly like many other users on here - firstly I must say it is a nice solution, the picture quality is very nice and unlike when I was using my 3Ghz Core 2 processor and xine output plugin with CoreAVC there are no issues with deinterlacing of sport channels / live content etc and it looks excellent with no stuttering etc - also leaves the CPU free.
However, there are some limitations of using one of these devices and the problem is, where does one get support for the issues? I have tried your support forum and found the answer to be that I should implement your own version of VDR (based on 1.4.7?) because the vanilla version does not currently use TS etc.
Are you selling single eHD cards solely for implementation within Reel devices? If so, I believe you should make this clear as I wasn't aware of this and other users won't be. Some of the problems I have when running eHD with VDR 1.7.0 are: -
1) Upgrading the latest testing version SVN often causes problems with compilation and you have to try and track down patches from other sites, or for bleeding edge SVN there simply aren't any available resulting in it not being possible to compile it. Would it be possible for Reel to host patches that will apply to vanilla VDR to make this operate, or have I missed this already?
2) Seeking forward/backward/play/pause/fast forward/fast rewind in recordings does not work very well and there is a bad delay and lag when using these functions. This is frustrating and irritates my wife!
3) You cannot play MKV files with the xine mediaplayer (although I think this also applies to Reel products)
4) Some channels don't work, e.g. BBC HD (very important for us Brits), SVT HD and others. Apparently BBC HD has been fixed in the Reel products but it doesn't work for vanilla VDR
5) If the stream is interrupted (i.e. weak signal) on HD channels / recordings then the picture does not recover until a channel change. This is a serious issue which needs to be addressed.
I hope the above helps, the eHD is a very nice solution but has some issues and for vanilla VDR users right now there doesnt appear to be any way to get them fixed.
Thanks,
Morfsta
On Wed, Dec 10, 2008 at 10:07:35AM +0000, Morfsta wrote:
Are you selling single eHD cards solely for implementation within Reel devices? If so, I believe you should make this clear as I wasn't aware of this and other users won't be. Some of the problems I have when running eHD with VDR 1.7.0 are: -
Well, they are sold for "hackers". As there is no "official" HDTV-capable vdr, RMM cannot provide support for any possible patch variant. AFAIK it is mentioned on the website that it works best with the reelvdr.
- Upgrading the latest testing version SVN often causes problems with
compilation and you have to try and track down patches from other sites, or for bleeding edge SVN there simply aren't any available resulting in it not being possible to compile it. Would it be possible for Reel to host patches that will apply to vanilla VDR to make this operate, or have I missed this already?
I don't think that RMM can make patches for vanilla vdr, because there is no standard how to handle DVB-S2/HDTV. You have multiproto systems, you have S2API. Neither one is used in the reelvdr. Currently there is the inofficial PES-solution for h264, but as Klaus wants to move to TS, it is already "deprecated". In the end, it would be a reelvdr ported to 1.7 just because there is an 1.7. That makes no sense when there is already a maintained 1.4-1.7 chimera from RMM which works out of the box. You can download the reelvdr source and compile it on your own. There are maybe a few compiler/make issues, but most of them are easy to fix.
- Seeking forward/backward/play/pause/fast forward/fast rewind in
recordings does not work very well and there is a bad delay and lag when using these functions. This is frustrating and irritates my wife!
Hm, what means "bad" delay? The reelvdr IMO has not such issues. The trickmodes are a bit slower in their reaction than on the latest FF card firmware, but for me it's Ok when looking at all the buffering stages that need to be notified and flushed...
- You cannot play MKV files with the xine mediaplayer (although I
think this also applies to Reel products)
We know. Something is wrong in the AVC-parser that affects some (not all) MKVs.
- Some channels don't work, e.g. BBC HD (very important for us
Brits), SVT HD and others. Apparently BBC HD has been fixed in the Reel products but it doesn't work for vanilla VDR
This is maybe an issue due to the PES remuxing as you need to differentiate between AC3 and MPEG during remuxing. As it seems BBC HD makes some strange things here. The reelvdr doesn't remux HDTV and records dumb TS, so we just had to fix it in the player detection.
- If the stream is interrupted (i.e. weak signal) on HD channels /
recordings then the picture does not recover until a channel change. This is a serious issue which needs to be addressed.
There are some watchdogs implemented (eg. to large timestamp jumps, internal buffer overflow, apparent decoder stalls etc.). But the overall handling is quite fragile, some decoder problems cannot detected. Can you reproduce these hangs reliably?
-
Andy Carter -
Clemens Kirchgatterer -
Frank Schmirler -
Georg Acher -
Goga777 -
Halim Sahin -
Helmut Auer -
Jörg Knitter -
Klaus Schmidinger -
Magnus Hörlin -
matthieu castet -
Morfsta -
Nicolas Huillard -
Pasi Juppo -
Pertti Kosunen -
Seppo Ingalsuo -
Stefan Hußfeldt -
Tony Houghton -
Udo Richter -
VDR User