Hello,
I read about the ongoing work at the OSD system. I have to confess, that I don't really miss a truecolor OSD, but what I miss is the possibility to configure the OSD for each output-device separately.
Currently I use a "backend"-vdr with budget-cards and an old fashioned FF. My TV is plugged to the old FF and I watch HD through a frontend-client with xineliboutput. That's not bad at all, but one shortcoming I noticed is, that configuration works for all output-devices. I tried the cool anthra-skin for HD - but then I don't get any OSD on FF.
Same happens with keyboard. Currently its easy to distinguish the keys, as they are created from different systems and for so have different keycodes. But when I update my TV to a HD system and use xineliboutput on the backend as well as the frontend, than there's no way to have separate keyboard configurations. Why I want different setups?
At the vdr I use a standard keyboard and the frontend is my desktop, where I use a Natural keyboard from M$ - which has a completely different layout of function-keys and additional keys. So it would be nice, to have sections in remote.conf that could be separated by output-device. Really great would be, if that sections could be created based on the IP of the client :)
kind regards
Gero
I don't know about any of that but I wonder if the new osd system will be able to maintain widescreen HD resolution even when viewing 4:3 SD channels. Or if it will behave as it currently does, stretches/shrinks according to the channel/recording you're watching. Preferrably it won't do that, or at least be something the user can toggle. My output is always 1920x1080. I opt not to scale SD content up to HD. This means that when I'm watching 4:3 SD content in 1920x1080, I have borders on the left & right, which I'm ok with. However, there's no reason I'm aware of why the osd can't still take advantage of the full 1920x1080.
I'm pretty sure this (among other things) were mentioned in previous threads on the subject though so I would guess the new system is well-thought out and has an unrestrictive design.
Hello,
VDR User wrote:
I don't know about any of that but I wonder if the new osd system will be able to maintain widescreen HD resolution even when viewing 4:3 SD channels. Or if it will behave as it currently does, stretches/shrinks according to the channel/recording you're watching. Preferrably it won't do that, or at least be something the user can toggle. My output is always 1920x1080. I opt not to scale SD content up to HD. This means that when I'm watching 4:3 SD content in 1920x1080, I have borders on the left & right, which I'm ok with. However, there's no reason I'm aware of why the osd can't still take advantage of the full 1920x1080.
That scaling, you're talking about is not related to the new OSD system. Scaling is part of the output device and at least xineliboutput can be configured to not to scale.
I was talking about OSD only - independant of the stream-format.
In the example I wrote, anthra was configured with 1920x1080 - when I watch TV from FF and hit the menue button, the screen will change to black font on black background :)
As far as I understand a statement of Klaus, the OSD will be different depending on the output device. So I wrote about my wish: if the OSD systems already are different, it would be nice to have different configurations too.
kind regards
Gero
On Sun, 16 Jan 2011 06:16:59 +0100 Gero geronimo013@gmx.de wrote:
Hello,
VDR User wrote:
I don't know about any of that but I wonder if the new osd system will be able to maintain widescreen HD resolution even when viewing 4:3 SD channels. Or if it will behave as it currently does, stretches/shrinks according to the channel/recording you're watching. Preferrably it won't do that, or at least be something the user can toggle. My output is always 1920x1080. I opt not to scale SD content up to HD. This means that when I'm watching 4:3 SD content in 1920x1080, I have borders on the left & right, which I'm ok with. However, there's no reason I'm aware of why the osd can't still take advantage of the full 1920x1080.
That scaling, you're talking about is not related to the new OSD system. Scaling is part of the output device and at least xineliboutput can be configured to not to scale.
I was talking about OSD only - independant of the stream-format.
In the example I wrote, anthra was configured with 1920x1080 - when I watch TV from FF and hit the menue button, the screen will change to black font on black background :)
As far as I understand a statement of Klaus, the OSD will be different depending on the output device. So I wrote about my wish: if the OSD systems already are different, it would be nice to have different configurations too.
configure a second vdr instance (on the client or the server) serving the xineliboutput, then you can have 2 configurations right now allready. Its not to much overhead actually :)
Hello,
thank you for your support!
Steffen Barszus wrote:
configure a second vdr instance (on the client or the server) ...
Hm - the client does not have a vdr-instance yet - and for so, the only thing I can configure there, is the IP of the server and the frontend to use. AFAIK all configuration (remote.conf) is done on the server. At least on my tests I had to add the XKeySym entries to the servers remote.conf
If there exists a kind of key mapping in the frontend already, please let me know.
I did not find a way to add client specific configuration yet.
Its not to much overhead actually :)
Well, I decide that, when I see the system load ...
So - I'm curious and willing to test. Do you know a url occasionally of someone who already did it? There are too much questions otherwise ...
kind regards
Gero
Am Sun, 16 Jan 2011 10:44:16 +0100 schrieb Gero geronimo013@gmx.de:
Its not to much overhead actually :)
Well, I decide that, when I see the system load ...
So - I'm curious and willing to test. Do you know a url occasionally of someone who already did it?
It is not really what you are looking for, but I implemented the picture in picture addon for yaVDR with this approach: http://www.yavdr.org/blog/blog-post/2010/12/01/announcing-yavdr-addon-pip-pi...
It is unbelievable simple and could give you an idea what the system load could be.
Gerald
Hello,
thank you for the link.
Gerald Dachs wrote:
It is not really what you are looking for, ...
Hm - may be I missed the real thing, but I did not find anything about installing 2 vdr instances on the same machine.
When I install a second instance on my backend, I need to know, what happen to the DVB-cards, who is responsable for recording, who resolves resource conflicts ... A lot of questions I'd like to know before I change my installation.
kind regards
Gero
Am Sun, 16 Jan 2011 12:19:41 +0100 schrieb Gero geronimo013@gmx.de:
Hello,
thank you for the link.
Gerald Dachs wrote:
It is not really what you are looking for, ...
Hm - may be I missed the real thing, but I did not find anything about installing 2 vdr instances on the same machine.
Maybe you didn't find anything about installing a second instance, because it has not to be done. You only have to start your already installed vdr with another configuration. This happens in the addon I pointed you to. You should really look more carefully into it.
Gerald
Hello,
Gerald Dachs wrote:
You should really look more carefully into it.
I beg your pardon!
I read that page for sure, but I can't state, that I understood much. I did not find any hint, that could change any of my issues either. May be that hint might be there, but then I did not understand it.
I'm willing to change my installation - no question - but I have very little sparetime, so I don't have the time to search for lots of additional links and follow each of them. Sorry.
Maybe you didn't find anything about installing a second instance, because it has not to be done.
When you look few postings back, I got the advice to install a second instance. I know, there are people around who run such a configuration, I read that hint quite often in the forum, but I did not find a page, where the problems of such an installation where disscussed or solved. Therefore I don't want to change my installation, before I know how to solve my upcoming issues.
With my current setup I do have certain issues. But meanwhile I know how to handle most of them, which means, I don't have any pressure to change my setup.
You only have to start your already installed vdr with another configuration. This happens in the addon I pointed you to.
I beg your pardon second time!
I don't use yavdr and I'm not willing to change my vdr to yavdr - so using your addon is no acceptable solution - no matter how good your addon might be! You know, that the reason for not using yavdr is ubuntu being the base of yavdr and that my rejection is NOT related to the yavdr team in any kind!
Anyway ...
You could explain me, what you did or show me a page, where that items are disscussed. No question, I'm willing to learn - but I'm not willing to change my basic principles or waste my time. I don't know - did you expect me to dive into your sources?
kind regards
Gero
Am Sun, 16 Jan 2011 16:27:47 +0100 schrieb Gero geronimo013@gmx.de:
I beg your pardon second time!
I don't use yavdr and I'm not willing to change my vdr to yavdr - so using your addon is no acceptable solution - no matter how good your addon might be! You know, that the reason for not using yavdr is ubuntu being the base of yavdr and that my rejection is NOT related to the yavdr team in any kind!
Sorry, but I think I don't ask you for too much, if I ask you to look into the sources of this addon yourself. It is really very easy. You can find it here https://launchpad.net/~yavdr/+archive/unstable-yavdr/+sourcepub/1385820/+lis...
Gerald
Hello,
Gerald Dachs wrote:
Sorry, but I think I don't ask you for too much, if I ask you to look into the sources of this addon yourself.
Ok - you could have mentioned that earlier.
I expected the solution in the blog article. ... but what stated Steffen: my expectations are wrong. Obviously!
Currently I'm working on a quite odious job - may be I'm quite a bit too huffish. Sorry for that.
kind regards
Gero
On Sun, 16 Jan 2011 16:27:47 +0100 Gero geronimo013@gmx.de wrote:
With my current setup I do have certain issues. But meanwhile I know how to handle most of them, which means, I don't have any pressure to change my setup.
As already said. Start a second vdr instance , using streamdev server and client for the dvb devices, and xineliboutput as output, start the plugins you want for the client on that instance. and you are done. Like that you can also start a second for another client if you are in need. The server vdr/vdr main instance will have all dvb devices, client vdr asking for the channels via streamdev as needed.
Thats what gerald was referring to. How you do that is up to you - you did not say anything about your installation, so help on this is impossible.
Steffen
Hello,
Steffen Barszus wrote:
As already said. Start a second vdr instance , using streamdev server and client for the dvb devices, and xineliboutput as output, start the plugins you want for the client on that instance. and you are done.
OK - I'll try that on my next bigger sparetime slot ;) When I setup my HD-vdr, I was not able to get streamdev running.
you did not say anything about your installation, so help on this is impossible.
Well - this thread has already become very OT, but ok:
my setup is:
Vdr-Backend: CPU: single-core Athlon 2500 reduced to 1900 MB: Gigabyte GA7N400S dvb: FF from Hauppauge, Budget from Mystique vdr: 1.7.16 from e-tobi with ACPI wakeup os: debian squeeze hd: removable for recordings net: gigabit TV: connected to FF AV: connected to FF via SP/DIF-Opto-converter
Vdr-Frontend (my desktop): CPU: Phenom II X4 965 MB: Gigabyte GA-880GM-UD2H os: debian squeeze net: gigabit Monitor: 60Hz standard
I start the frontend with this script (as mentioned earlier - I don't have a vdr installation at that machine): --- <snip> --- #!/bin/bash # name of vdr-host vdr='vdr'
# options for xine postprocessing post='tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1'
# options: tcp | udp transport='tcp'
# options: sxfe | fbfe display='sxfe'
vdr-$display --width=1200 --height=720 --buffers=5000 --post $post xvdr:TCP://$vdr:37890 --$transport --- <snap> ---
kind regards
Gero
Am 16.01.2011 05:35, schrieb Gero:
I read about the ongoing work at the OSD system. I have to confess, that I don't really miss a truecolor OSD, but what I miss is the possibility to configure the OSD for each output-device separately.
Currently I use a "backend"-vdr with budget-cards and an old fashioned FF. My TV is plugged to the old FF and I watch HD through a frontend-client with xineliboutput.
You're using a very special situation here, as xineliboutput is IMHO the only output device that can promote itself to be 'the' output device at runtime. VDR itself has not much to do with this switching, and doesn't know in advance how many of its devices suddenly may or may not be the output device. Keeping multiple configurations for OSD persistently would break a lot (including plugins), and will probably have lots of issues. (I already can imagine OSD size depending on DVB driver load order...)
Its probably a lot easier to solve this at the output side within xineliboutput. xineliboutput could easily backup the OSD parameters when replacing the primary device, set his own parameters, and set them back when disconnecting. Probably needs some care to make sure that parameters get restored in any case, but solvable.
Cheers,
Udo
Hello,
Udo Richter wrote:
Am 16.01.2011 05:35, schrieb Gero:
Currently I use a "backend"-vdr with budget-cards and an old fashioned FF. My TV is plugged to the old FF and I watch HD through a frontend-client with xineliboutput.
You're using a very special situation here, as xineliboutput is IMHO the only output device that can promote itself to be 'the' output device at runtime.
Well - that is a point, I don't like at all!
So if someone watches TV with the FF card, the TV gets dark as soon as I start the xineliboutput frontend. I don't know anything from the vdr internals - I'm just a user.
From my (user-)point of view the vdr may not break, if a client does an error. Currently when I forget to switch to a SD channel on the xineliboutput frontend before stopping that frontend, the vdr is not operable for the FF- user. There's no way to recover. I have to start the xineliboutput frontend, change the channel and then stop that frontend again.
VDR itself has not much to do with this switching,
Best would be, to be able to switch this kind of switching off completely.
and doesn't know in advance how many of its devices suddenly may or may not be the output device.
That's how it should be - at least from my point of view ;)
Keeping multiple configurations for OSD persistently would break a lot (including plugins), and will probably have lots of issues.
Well, after all it was just a wish :)
I think, the task to create a new OSD system is neither simple nor small - so lots of issues have to been taken into account. I like to think about upcoming issues in advance and I'm sorry, but I don't like that pessimists, that only know to talk about things, that are impossible, that should never get touched, ....
Its probably a lot easier to solve this at the output side within xineliboutput.
So you change a possible issue into a 'NMP'-issue - not very smart. (NMP stands for "not my problem")
kind regards
Gero
On Sun, 16 Jan 2011 12:09:34 +0100 Gero geronimo013@gmx.de wrote:
Hello,
Udo Richter wrote:
Its probably a lot easier to solve this at the output side within xineliboutput.
So you change a possible issue into a 'NMP'-issue - not very smart. (NMP stands for "not my problem")
actually i think its wrong setup on your side. call it "wrong expectations". see Geralds answer. As allready said, put a streamdev client locally on the server or put vdr on the client and use xineliboutput on the client. You actually want streamdev for client/server. xineliboutput is just an output plugin , not client server.
Hello,
Steffen Barszus wrote:
actually i think its wrong setup on your side. call it "wrong expectations".
That - of cause - may be true!
I'm quite new to client/server vdr. I tried lot of things and my current installation is the only, I succeeded to get into play.
... and - after all - it works quite fine!
My issues are issues in the sense of "you put sugar in your coffee?" and not the question, whether it is possible to create coffee. So don't give my issues to much importance.
I think - there are several aspects of vdr, that could be improved. The question is not, whether improvement is possible, but if that aspect has enuf relevance to start thinking about improvement. But - that's not my decision.
I only can talk about what I like to get improved.
kind regards
Gero
Al 16/01/11 12:09, En/na Gero ha escrit:
Currently when I forget to switch to a SD channel on the xineliboutput frontend before stopping that frontend, the vdr is not operable for the FF- user. There's no way to recover.
I had the same issue with vdr-xine and the dxr3 plugin. Maybe the ff output should do something similar to what I did with the dxr3 plugin: if the stream is hd (actually h264), instead of sending it to the dxr3 (and crashing it), just show a message that the video stream is not supported. Everything else (audio, osd), still works fine.
Bye
-
Gerald Dachs -
Gero -
Luca Olivetti -
Steffen Barszus -
Udo Richter -
VDR User