Re: [vdr] j2 rgb output board
Ondrej Wisniewski wrote: > There is a web site in english introducing the DVB-S Extension board. > You can find all necessary information here: > http://www.vdr-portal.de/board/thread.php?threadid=14942 Sorry, the correct link should be http://www.kdvelectronics.eu/DVB-J2/DVB-S_J2.html ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] j2 rgb output board
Torgeir Veimo wrote: > I've found the rgb output protection board for use with the J2 jumper > on certain FF cards at the VDR portal; > http://www.vdr-portal.de/board/thread.php?threadid=5893&sid=ec2e4e55466d75685541f2d08a1c6044&hilight=piggyback > > There's also a thread with an overview of existing boards here; > http://www.vdr-portal.de/board/thread.php?threadid=14942 > > However, google translate has been failing to translate anything > German for the last month, so I'm wondering if someone knows if ; > > - there are premade PCBs available from somewhere? > - any other similar protection boards for rgb output can be found > ready made from somewhere? > - there are any updated or later discussions about RGB output PCBs for > use with FF card via the J2 jumper block (preferable in english)? > There is a web site in english introducing the DVB-S Extension board. You can find all necessary information here: http://www.vdr-portal.de/board/thread.php?threadid=14942 Another interesting board was presented recently here (in german): http://www.vdr-portal.de/board/thread.php?threadid=62843 I guess you can write a private message to the author seaman in order to ask how to purchase it. Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPIA-ML6000 and vdr-xine full screen?
Simon Baxter wrote: > Hi group! > > Has anyone tested running an EPIA ML6000 fanless motherboard with vdr-xine? > > The spec's only say "MPEG-2 Accelerator" rather than "Decoder/Accelerator" - > will it work with a VGA 1366x768 16:9 full screen? I have used vdr xineliboutput running on an EPIA-M1 which has the same CLE266 MPEG decoder chip as your board. Works with fullscreen 1680x1050 and hardware decoding. Needs the OpenChrome graphics driver, of course. Usually also "strange" resolutions as yours work fine with the appropriate modeline in the xorg.conf. Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] basic set-up for vdr and HVR 4000 in Ubuntu 7.10
> I have installed the plugin with apt-get , no problem
>
> vdr -V
> vdr (1.5.16/1.5.15) - The Video Disk Recorder
>
> but when I run vdr with the plugin I got
> [EMAIL PROTECTED]:~# vdr -P"xineliboutput --local=sxfe --video=xv
> --audio=alsa
> --remote=none"
> vdr: ./PLUGINS/lib/libvdr-xineliboutput.so.1.5.15: kan gedeeld
> objectbestand niet openen: Bestand of map bestaat niet ( can't open
> objectfile.File or map is not existing)
> what is here still missing
>
> Gaston
Man, you have some confusion here! Looks like you are mixing up
different vdr versions. I guess you compiled vdr on your own (1.5.16)
and installed xineliboutput from the Ubuntu 7.10 repos which was built
for vdr 1.4.7. That will never work! So if you want to get anything
running just compile *everything* from source or install *everything*
via apt-get.
Furthermore, if you are not using the default paths where vdr is looking
for the needed libs, you need to specify them via command line
parameters ('man vdr' is your friend). Good luck :-)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] basic set-up for vdr and HVR 4000 in Ubuntu 7.10
> Thanks Ondrej > > I have followed the link and installed xineliboutput, but make plugins give > > Plugin xineliboutput: > make[1]: Map '/usr/local/vdr-1.5.16/PLUGINS/src/xineliboutput-1.0.0rc2' > wordt binnengegaan > g++ -O3 -pipe -Wall -Woverloaded-virtual -fPIC -g -c -D_GNU_SOURCE > -DPLUGIN_NAME_I18N='"xineliboutput"' -D_REENTRANT -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -DXINELIBOUTPUT_VERSION='"1.0.0rc2"' > -DUSE_ICONV=1 -Wall -I../../../include -o device.o device.c > ../../../include/vdr/osd.h:409: let op: 'virtual cOsd* > cOsdProvider::CreateOsd(int, int, uint)' was hidden > osd.h:62: let op: by 'virtual cOsd* > cXinelibOsdProvider::CreateOsd(int, int)' > device.c: In member function 'virtual void > cXinelibDevice::MakePrimaryDevice(bool)': > device.c:330: fout: cannot allocate an object of abstract type > 'cXinelibOsdProvider' > osd.h:54: note: because the following virtual functions are pure > within 'cXinelibOsdProvider': > ../../../include/vdr/osd.h:409: note: virtual cOsd* > cOsdProvider::CreateOsd(int, int, uint) > make[1]: *** [device.o] Fout 1 > make[1]: Map '/usr/local/vdr-1.5.16/PLUGINS/src/xineliboutput-1.0.0rc2' > wordt verlaten > > *** failed plugins: skincurses xineliboutput > > What is missing here, does I have to install other plugins first? > > gaston Why don't you just install the binary packages with apt-get? They are already in the Ubuntu repositories. It should be as easy as typing: sudo apt-get install vdr vdr-plugin-xineliboutput If you prefer to compile everything from source you will need to resolve all the dependencies manually which could be quite a long shot. Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] basic set-up for vdr and HVR 4000 in Ubuntu 7.10
ga ver wrote: > Hi, > > What is the basic configuration(setup) for watching sattelite TV with a > Hauppauge HVR 4000 card in Ubuntu 7.10. > Drivers and scanning are OK, Kaffeine 0.8.4 is working, but how does I > start with vdr? > > Thanks in advance > > Gaston You should install at least the packages "vdr" (main program) and "vdr-plugin-xineliboutput" (grafical frontend) from the Ubuntu repos. Then you need to modify most likely some config files (e.g. channels.conf) for your setup. For more information http://www.linuxtv.org/vdrwiki/index.php/Main_Page is a good starting point. Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD-TV hardware decoding on motherboard instead of waiting for FF DVB-S2 card
Ondrej Wisniewski wrote: > This board mounts a CX700M2 chipset which features MPEG2/4 hardware > decoding. It has DVI and Y/Pb/Pr video output as well as analog and > SPDIF audio (coaxial and optical). So that's everything we need, isn't it. Well, looks like the people who pointed out that this chip doesn't decode h.264 are right. Neither could I find any other decoder chip on the VIA web pages that would do that. So this is actually a "no go" for the EPIA boards for decoding HD-TV video. That means I was wrong and we really *don't* have the needed hardware *today*, not to mention Linux support. Remains to be seen if VIA (or some other manufacturer) comes up with a small, low power consumption MB with h.264 hw decoding or if we see a FF DVB-S2 card before that. In the meantime there is no hurry, I'm happy with the current VDR :-) Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] HD-TV hardware decoding on motherboard instead of waiting for FF DVB-S2 card
With VDR getting ready for HD-TV it seems that today the MPEG4 decoding can only be done on a high end processor or an external decoder card. Many people are still waiting for a FF DVB-S2 card but it doesn't look very promising at the moment. So I was wondering if it would be possible to use the on board video decoder chips of the VIA EPIA boards like the VIA EPIA EX15000G http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=450 This board mounts a CX700M2 chipset which features MPEG2/4 hardware decoding. It has DVI and Y/Pb/Pr video output as well as analog and SPDIF audio (coaxial and optical). So that's everything we need, isn't it. I know, currently the OpenChrome video driver doesn't support MPEG2/4 video decoding for the CX700M2 and there are probably other things missing from the software support side. But from what I see, this or a similar motherboard in combination with a budget DVB-S2 card have all the hardware features that are needed to have HD-TV. So we actually have the proper hardware platform *today* for a quite a low budget. So if all the efforts go into driver and application development for such a platform, there is no need to wait for FF DVB-S2 cards. Or am I missing something here? -- Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput with xxmc: slow OSD
Tony Grant wrote: > Le lundi 28 janvier 2008 à 12:07 +0100, Ondrej Wisniewski a écrit : > > Sorry I forgot to say I am using Fedora Core 8. There is an issue with > libxcb and threads - it is fixed in OpenSuze10.3 says Reinhard. > > With the OSD I have increase in CPU load and, in the terminal I am > running Xine from, warning that I don't have enough colors etc. Can't > zap from horizontal to vertical polarization. > > Screen goes blue and VDR restarts > > I am currently using the multiproto driver linked from the 1.5.14 > announcement. I am using Ubuntu 7.10 with xine lib from the repos. Here's the problem I encounter. Might be the same bug you are talking about: VDR is running with xineliboutput plugin. Remote frontend sxfe is started on the same PC: $ vdr-sxfe --video=xxmc xvdr://127.0.0.1 Initially I get video and audio just fine with HW decoding. But when I switch channel and the OSD is shown I get lots of these: video_out: Warning! Out of xx44 palette colors! And shortly after the crash: video_out_xxmc: Using software decoding for this stream. libmpeg2: output port has XxMC capability AFD changed from -2 to -1 video_out_xxmc: Using software decoding for this stream. video_out_xxmc: Using hardware decoding for this stream. *** glibc detected *** vdr-sxfe: double free or corruption (!prev): 0x086d6558 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0xb7c72d65] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c76800] /usr/lib/xine/plugins/1.1.8/xineplug_vo_out_xxmc.so[0xb6656685] Looks like a xine problem, specifically the xxmc plugin. :-( Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput with xxmc: slow OSD
Tony Grant wrote: > > There is a problem with xine, the openchrome driver and VDR. You are too > slow - I am seeing 9-12% CPU with current openchrome even with this bug. > > I am using vdr-xine rather than xineliboutput > > Cheers > > Tony Hi Tony, that was not the answer I was hoping for ;-) Are you saying that there is a bug regarding OSD usage with the combination xine, openchrome and VDR? Can you explain a little more? Any ways around that? Regarding CPU load I need to check that again at home. I was reporting the overall CPU load on my PC. I should probably check just the consumption of VDR and sxfe. To complicate things the VDR get's it's videostream using streamdev-client from the server box. -- Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput with xxmc: slow OSD
Hi, I am experimenting with xineliboutput using the xxmc video driver for the local sxfe frontend on an EPIA-M1 board with CLE266. I have the OpenChrome Drivers installed. MPEG2 HW decoding seems usually to work, I get around 25% CPU usage. However, when I bring up VDRs OSD everything becomes painfully slow. Why is that? Are there any setup options I can use to make the OSD work decently? Thanks, -- Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
Klaus Schmidinger wrote: > > Some comments in this thread (and others) sound as if there is > an imminent need to switch to HDTV/H.264, because otherwise we > won't be able to watch tv any more within a few months. I don't > see any real incentive in taking all the extra efforts to do > HDTV. The programmes I usually watch are all broadcast in normal > MPEG2, SDTV. Even if I had the ability to receive HDTV, I would have > to pay extra to actually see anyting - so what's the point? > I completely agree with Klaus on that point. All the HD hype right now is just the industries way of pushing a new technology and selling new hardware (decoders, TV sets, ...) to the consumers that didn't really ask for it. Seems a bit like some years ago when 16:9 TV sets was a *must have*. But there were actually almost no anamorph 16:9 transmissions and most people with their brand new sets were happily watching the news speaker or their favourite soap opera stars with squashed heads. That has somehow changed and even the news are in 16:9 anamorph format on German TV now. But how long did it take? How many channels are available now which transmit quality HD content (apart from demo channels)? I don't think it's a significant number to make VDR useless because you can't watch them with it. Of course there are alternatives for the "early adaptors" so that's fine. I am sure VDR will also support HD some time in the future. It just doesn't seem necessary right now. Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPIA mpeg2/4 quality on vdr-xine
Tony Grant wrote: > I have the older M1 CLE266 and picture quality on VGA out is good. I > am at 1440x900. MPEG2 is hardware decompressed and MPEG4 is accelerated > on the SP series. > > Cheers > > Tony How did you enable the MPEG2 decoder? I enabled the xxmc option in xine (xvmc caused crashes). Are there other ways? CPU utilization here is at around 25% during DVD playback on an EPIA-M1. Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvd plugin - WAF
You let your wife operate your VDR ? ;-) Torgeir Veimo wrote: > The DVD plugin works reasonably well on a technical level, but my gf has > a hard time operating it at times; it's hard to remember which keys are > which when you only use it once in a while. > > Why is it not possible to use the normal cursor keys on the remote for > the same functions in DVD playback mode, instead of using the numerical > keys? > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
Ondrej Wisniewski wrote: So I propose that VDR should always tune to a channel that is requested, get the current CA value from the data stream (and not from the channels.conf) and then decide if the channel can be shown/recorded. Does that sound like a good solution? Any obvious drawbacks? @Klaus: is there any chance of integrating this modification in an upcoming version of VDR? Even though it looks like this topic has not raised much interest, I think it is important and really should be addressed. VDR has failed recording periodically scheduled programs many times here because the program transmitted after the recording was encrypted. So the next scheduled recording the following day was not started because the channel was marked encrypted in the channels.conf. And VDR mainly being a "video recorder" this really is a serious bug. Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
Stone wrote: > Is there an easy way to fix this? Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't. With this modification to dvbdevice.c, I wonder if VDR will still crash when a timer goes off on a channel and all the sudden it becomes encrypted. This would normally cause a broken data stream and VDR would do an emergency exit. Regards. I remember these crashes with VDR 1.2.6 but if I'm not wrong there are no restarts any more with 1.4.5. If a channel gets encrypted during live view, the picture just freezes. Then I can safely switch to another channel manually. If the encryption starts during a recording, the recording just stops. But now I'm not so sure any more because VDR could just have restarted without me noticing. And after the restart it doesn't continue the recording because now the CA value is set in the channels.conf Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
Luca Olivetti wrote: En/na Ondrej Wisniewski ha escrit: I am using VDR 1.4.5 with the integrated auto pid feature and without any CAM. When tuning to an encrypted channel, the CA value gets set accordingly and "channel not available" is displayed. So far so good. However there are channels that encrypt only certain programs and are free the rest of the time. When tuning to this "free" channel while the program is encrypted, the CA value will be set and "channel not available" shown. But when tuning to the same channel again when it is not encrypted any more it seems that VDR just checks the CA value and displays "channel not available" instead of checking the currently broadcast CA value. So the channel cannot be watched even if it is free in the moment. This is quite annoying and decreases the WAF a lot :-/ Is there an easy way to fix this? Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't. Bye OK, that seems like a good workaround. But it is not a real solution. I mean I still want to see "channel not available" but only when it is really not available (it is currently encrypted). That would be the correct behaviour. Furthermore I am not sure what happens when a recording on such a channel starts and it is really encrypted. The current solution is safe because it doesn't tune to the channel if the CA value is set. However it has the drawback of not recording even if the channel might be FTA again (that's a real show stopper). So I propose that VDR should always tune to a channel that is requested, get the current CA value from the data stream (and not from the channels.conf) and then decide if the channel can be shown/recorded. Does that sound like a good solution? Any obvious drawbacks? Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Handling of temporarily encrypted channels
I am using VDR 1.4.5 with the integrated auto pid feature and without any CAM. When tuning to an encrypted channel, the CA value gets set accordingly and "channel not available" is displayed. So far so good. However there are channels that encrypt only certain programs and are free the rest of the time. When tuning to this "free" channel while the program is encrypted, the CA value will be set and "channel not available" shown. But when tuning to the same channel again when it is not encrypted any more it seems that VDR just checks the CA value and displays "channel not available" instead of checking the currently broadcast CA value. So the channel cannot be watched even if it is free in the moment. This is quite annoying and decreases the WAF a lot :-/ Is there an easy way to fix this? -- Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [EMAIL PROTECTED]
Marco Skambraks wrote: I know that hauppauge will not develope a FF for hdtv are you sure that technotrend is working on a FF card? or is it just a guess? marco According to rumours in the VDR-Portal they are. But nothing specific seems to be known yet. Looks like dvbshop.tv has some contact with them. Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [EMAIL PROTECTED]
Klaus Schmidinger wrote: Halim Sahin wrote: Hello, On Mo, Jan 29, 2007 at 06:43:40 +0100, Klaus Schmidinger wrote: Yes, I do plan to do this. Yesterday I've installed my DVB-S2 card in a test box, so hopefully I'll be able to start digging into this one of these days... FF-Card??? I wish ;-) It's a Technotrend S2-3200 HDTV-S2, unfortunately with the C1L chip version. So if you get yourself such a card, you might want to make sure you get one with the C2L version (see Manu Abraham's message at http://www.linuxtv.org/pipermail/linux-dvb/2007-January/015585.html). Don't know personally if this actually is a problem, because so far I haven't started working with it. Klaus There is a promising FF solution being developed by Micronas. Dual DVB-S2 receiver, hardware H.264 decoding and HDMI output. http://www.micronas.com/pressroom/press_releases/articles/149309/index.html?newslang=1 It's has a PCI express card so Klaus might have to bye a new PC after all ;-) But also Technotrend might get their DVB-S2 FF card to the market sooner or later. Ondrej ... P.S. Funny subject for this thread. Maybe it was supposed to be a private conversation? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] frontend tuning timeouts break DD AC3 stream
I tried to disable the EPG scan (EPG scan timeout set to 0) and couldn't actually see any audio disruptions any more in AC3. So the culprit really seems to be the EPG scan. But why does this problem only occur with AC3 audio? Any ideas? Ondrej ... Ondrej Wisniewski wrote: I just want to add that I am experiencing the same problems here: short DD AC3 stream breaks during playback and a frontend tuning timeout message in the log at the same time. There is no problem with PCM audio or live TV. I am using a single card system with TT 1.6 DVB-s, VDR 1.4.5 and latest Firmware F12623. So I guess that my VDR does an EPG scan only during playback and that's when I get the problem. I will try to disable the EPG scan and see if anything changes. Ondrej ... Thomas Bartschies wrote: Hi, I'm experiencing the usual DD A3 stream breaks here. Now I have discovered that the epg scan seems to trigger them, by tuning to some channels. vdr logs frontend tuning timeouts synchronously to the stream breaks my AV Receiver displays. They can only be caused by a background job like the epg scan. Also the timeouts occur on the primary card, which seem to be sometimes used to make scans. I'm not sure if the tuning timeouts were caused because the channels are encrypted, or by invalid data in the channels.conf. But that should have no meaning here. The timeouts can be caused by the firmware or driver, or in vdr by tuner thread locking issues. I need help to sort this out. I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing. Best Regards, Thomas ___ 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
Re: [vdr] frontend tuning timeouts break DD AC3 stream
I just want to add that I am experiencing the same problems here: short DD AC3 stream breaks during playback and a frontend tuning timeout message in the log at the same time. There is no problem with PCM audio or live TV. I am using a single card system with TT 1.6 DVB-s, VDR 1.4.5 and latest Firmware F12623. So I guess that my VDR does an EPG scan only during playback and that's when I get the problem. I will try to disable the EPG scan and see if anything changes. Ondrej ... Thomas Bartschies wrote: Hi, I'm experiencing the usual DD A3 stream breaks here. Now I have discovered that the epg scan seems to trigger them, by tuning to some channels. vdr logs frontend tuning timeouts synchronously to the stream breaks my AV Receiver displays. They can only be caused by a background job like the epg scan. Also the timeouts occur on the primary card, which seem to be sometimes used to make scans. I'm not sure if the tuning timeouts were caused because the channels are encrypted, or by invalid data in the channels.conf. But that should have no meaning here. The timeouts can be caused by the firmware or driver, or in vdr by tuner thread locking issues. I need help to sort this out. I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing. Best Regards, Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
