Re: [vdr] XBMC + VDR 1.7.0
Quoting jori.hamalai...@teliasonera.com: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr 1:30 to boot.. :) My own integration needs 0:15 :( , but I am working on it. Gerald This message was sent using IMP, the Internet Messaging Program. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
But Suspend-to-RAM (S3) should work under Ubuntu? Or not? -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von jori.hamalai...@teliasonera.com Gesendet: Freitag, 12. Dezember 2008 09:04 An: vdr@linuxtv.org Betreff: Re: [vdr] XBMC + VDR 1.7.0 http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr 1:30 to boot.. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Goga777 schrieb: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Maybe this is a trivial question, but how does he switch between XBMC and VDR? AFAIK there is no XBMC mailing list, and I did not find the time to take a closer look in the forums... I have read (and thought) about some little script that switches between XBMC and VDR, and there was one solution mentioned here using LIRC. But the way it is shown on the video it look like a real integration. And why does the VDR state press any key to cancel shutdown? I thought that VDR should be running all the time in the background... Currently, I use the tv-out of the gfx card for XBMC and the tv-out of my FF for VDR, switching simply by selecting a different video input on my amplifier, but with HD, the FF might replaced within the next 12 months. With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Jörg Knitter schrieb: Goga777 schrieb: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Maybe this is a trivial question, but how does he switch between XBMC and VDR? AFAIK there is no XBMC mailing list, and I did not find the time to take a closer look in the forums... I have read (and thought) about some little script that switches between XBMC and VDR, and there was one solution mentioned here using LIRC. But the way it is shown on the video it look like a real integration. And why does the VDR state press any key to cancel shutdown? I thought that VDR should be running all the time in the background... Currently, I use the tv-out of the gfx card for XBMC and the tv-out of my FF for VDR, switching simply by selecting a different video input on my amplifier, but with HD, the FF might replaced within the next 12 months. With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hello! That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. Greetings Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Niko Ringelstein wrote: Jörg Knitter wrote: Goga777 wrote: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr Maybe this is a trivial question, but how does he switch between XBMC and VDR? I have read (and thought) about some little script that switches between XBMC and VDR, and there was one solution mentioned here using LIRC. But the way it is shown on the video it look like a real integration. That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Jörg Knitter schrieb: Niko Ringelstein wrote: Jörg Knitter wrote: Goga777 wrote: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr Maybe this is a trivial question, but how does he switch between XBMC and VDR? I have read (and thought) about some little script that switches between XBMC and VDR, and there was one solution mentioned here using LIRC. But the way it is shown on the video it look like a real integration. That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr As far as I know it connects via streamdev-client. Concerning the mainmenu entry, I don't know the skin he is using. It might be a favourite entry, that's what I use in the PM3HD skin. Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Niko Ringelstein wrote: Jörg Knitter wrote: In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg As far as I know it connects via streamdev-client. Then, IMHO the OSD would be missing and the switch time would be longer - that´s why I ask. So I assume that he is using sxfe-vdr... Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
On Fri, 12 Dec 2008 11:54:35 +0100, Jörg Knitter joerg.knit...@gmx.de wrote: Niko Ringelstein wrote: Jörg Knitter wrote: In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg As far as I know it connects via streamdev-client. Then, IMHO the OSD would be missing and the switch time would be longer - that´s why I ask. So I assume that he is using sxfe-vdr... Joerg Anyone using VDR together with Freevo? It assumes VDR is run headless in the background with softdevice or xineliboutput or vdr-xine plugin... When user selects VDR from Freevo menu it will just launch softdevice frontend and disconnect Freevo from LIRC (via Freevo plugin). When you close softdevice screen, it disconnects VDR from the LIRC (there is a special SVDR command for it). Probably something similar is used with XMBC. Piotr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I see no reason to use xbmc as vdr frontend. Personally I use lirc/irexec to switch between vdr-sxfe and xbmc. The DVD Player button switches to xbmc, and Live TV or Recorded TV for vdr-sxfe. As for startup times, my clients use 28-30W and have no fans or hdd's so I have them on 24/7. At least during Swedish winter a have use for them anyway... /Magnus H ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Jörg Knitter schrieb: Niko Ringelstein wrote: Jörg Knitter wrote: In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg As far as I know it connects via streamdev-client. Then, IMHO the OSD would be missing and the switch time would be longer - that´s why I ask. So I assume that he is using sxfe-vdr... Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I meant the plugin connects via stramdev, he is using vdr-sxfe or softdevice! Probably the best solution would be a xbmc plugin using the vompserver protocol. I am no coder, but there already exists qtvomp which maybe could be used somehow. vomp is working very well for me on a nomal tv with a mediamvp but i don't want to use it with my flatscreen because it only has rgb out, no hdmi. Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] projects.vdr-developer.org launched
On Friday 12 December 2008 01:43:26 Tobi wrote: The main goal for this is, to be a community effort to continue the development of such orphaned VDR plug-ins and give them a new home. This sounds interesting. I'm maintaining the tvonscreen plugin for Fedora and tvonscreen has not had any releases for quite a while. I've contacted the developer via e-mail, in case he's not interested in tvonscreen development anymore (or too busy or something), maybe we could set up a project for tvonscreen as well. Currently the Fedora package is carrying 02_tvonscreen-1.0-fixes.dpatch from e-tobi, tvonscreen-1.0.141-1.5.3.diff from toms-cafe.de and tvonscreen-1.0.141-i18n-1.6.patch from Mandriva (by Anssi Hannula). It would be interesting to merge these (and maybe some other patches people have written) to a new source code tree, maybe try to get some new translations and eventually even do new releases. -- Ville-Pekka Vainio ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] projects.vdr-developer.org launched
On Fri, 12 Dec 2008, Tobi wrote: Hi Tobias The main goal for this is, to be a community effort to continue the development of such orphaned VDR plug-ins and give them a new home. Could you start a new project for ttxtsubs-plugin? The patch is huge and the original plugin author has abandoned the whole VDR thing as far as know. I haven't been keen enough to provide a full changelog for modifications (or even to use the plugin!), but I can dig out contributors from my mail archives if required. Anyway it could be a good idea to rename somehow these community forks of plugins in order to differentiate them from the original ones: e.g. osdteletext - osdteletextcm, ttxtsubs - ttxtsubscm (cm=community maintained). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and Switching time
Found a solution for the delay, please try it and report if it helps you and even more important if it doesn't break something else. Special testing should be done for HD channels with high streams. Change line 77 in xine_input_vdr.c from: #define METRONOM_PREBUFFER_VAL (4 * 9 / 25 ) to: #define METRONOM_PREBUFFER_VAL 128//(4 * 9 / 25 ) Some documentation says something that large buffers are needed for mosaic channels (what is it anyway?). Looks like there is another buffer somewhere on the way... Please report the results. Thanks. On Thu, Dec 11, 2008 at 11:23 PM, Alex Betis alex.be...@gmail.com wrote: Gents, could you please run vdr-sxfe with --verbose flag and check if you see the prebuffer= line in console output when you switch the channel? Please state the number you see there and please write again your vdr, xine-lib and xinelibout versions. Thanks. 2008/12/11 Rolf Ahrenberg rahre...@cc.hut.fi On Thu, 11 Dec 2008, Goga777 wrote: 4. vdr 1.7.0(1) xineliboutput, directfb - 2-3 sec, xineliboutput, x11 - 2-4 sec seems it's due to of tcp/ip and pipes which are using xineliboutput Well, I have vdr-1.6.0 and xinelibout-cvs with vdr-sxfe on my development setup using latest kernel drivers (S2API, DVB-T card) and haven't ever noticed as slow zapping as you documented: the channel switching time is about one second. BR, -- rofa ___ 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] xineliboutput and Switching time
On 12/12/2008, Alex Betis alex.be...@gmail.com wrote: Found a solution for the delay, please try it and report if it helps you and even more important if it doesn't break something else. Special testing should be done for HD channels with high streams. Change line 77 in xine_input_vdr.c from: #define METRONOM_PREBUFFER_VAL (4 * 9 / 25 ) to: #define METRONOM_PREBUFFER_VAL 128//(4 * 9 / 25 ) so from 14400 to 128 lol, making it smaller helps with higher streams? Some documentation says something that large buffers are needed for mosaic channels (what is it anyway?). Looks like there is another buffer somewhere on the way... Please report the results. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and Switching time
On Fri, Dec 12, 2008 at 4:47 PM, Theunis Potgieter theunis.potgie...@gmail.com wrote: On 12/12/2008, Alex Betis alex.be...@gmail.com wrote: Found a solution for the delay, please try it and report if it helps you and even more important if it doesn't break something else. Special testing should be done for HD channels with high streams. Change line 77 in xine_input_vdr.c from: #define METRONOM_PREBUFFER_VAL (4 * 9 / 25 ) to: #define METRONOM_PREBUFFER_VAL 128//(4 * 9 / 25 ) so from 14400 to 128 lol, making it smaller helps with higher streams? I wrote that special testing is needed for high streams, I didn't write that it helps it somehow. I personally don't have HD channels available, so can't test myself. As I also wrote, there is probably another buffer on the way (driver?), so it might be enough. By the way, I'm more than sure there is a buffer in driver since scan-s2 gets messages from previous channel after it already tuned to a new one. At least with stb0899 (TT3200 and Twinhan 1041) driver. Some documentation says something that large buffers are needed for mosaic channels (what is it anyway?). Looks like there is another buffer somewhere on the way... Please report the results. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 1.7.1 + multiple audio streams on channel = buffer problem
Hi, I'm with 1.7.1 and observe some buffer problems on channels with multiple audio streams. Bandwidth of audio steams probably make a different since I observe problems with channel that has 6 audio tracks or even 4 audio tracks, while there are other channels with 4 tracks that have no problem at all. I guess thats a result of moving to TS. Any hint what buffer should I increase? VDR log shows the following: Dec 12 19:37:09 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:09 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:13 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:14 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:14 htpc vdr: [21748] buffer usage: 90% (tid=21747) Dec 12 19:37:15 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:18 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:19 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC1): skipped 348 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC5): skipped 588 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC4): skipped 1260 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC0): skipped 1260 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC3): skipped 1356 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC2): skipped 1660 bytes while syncing on next audio frame Dec 12 19:37:22 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:23 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:23 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:27 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:27 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:27 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC4): skipped 636 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC0): skipped 636 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC3): skipped 732 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 2 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC2): skipped 57 bytes to sync on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC5): skipped 1756 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC1): skipped 756 bytes to sync on next audio frame Dec 12 19:37:35 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:36 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:36 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:39 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:40 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:40 htpc vdr: [21748] buffer usage: 90% (tid=21747) Dec 12 19:37:40 htpc vdr: [21748] buffer usage: 60% (tid=21747) Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Wed, Dec 10, 2008 at 10:07:35AM +, 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. 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? 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. 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! 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... 3) 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. 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 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. 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. 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? -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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! ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Anyone using VDR together with Freevo? It assumes VDR is run headless in the background with softdevice or xineliboutput or vdr-xine plugin... Sure - thats the default Gen2VDR installation :) -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Can I start vdr and xineliboutput separately? For example, vdr starts when computer is on, so it works always. But xinelibout is starting when I close xbmc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
BoNuZZZ a écrit : Can I start vdr and xineliboutput separately? For example, vdr starts when computer is on, so it works always. But xinelibout is starting when I close xbmc. Yes. You run the plugin in VDR, with no local front-end. You then launch vdr-sxfe (X) or vdr-fbfe (DirectFB) front-end on the machine when you want to display VDR output. VDR runs as a headless daemon. A single vdr-??fe can connect to the xineliboutput plugin at the same time. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] projects.vdr-developer.org launched
Ville-Pekka Vainio wrote: tvonscreen has not had any releases for quite a while. I've contacted the developer via e-mail, in case he's not interested in tvonscreen development anymore (or too busy or something), maybe we could set up a project for tvonscreen as well. Of course, you're welcome! Just follow the instructions on http://projects.vdr-developer.org/wiki/project-management/Registering_a_new_project Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
2008/12/12 Magnus Hörlin mag...@alefors.se That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I see no reason to use xbmc as vdr frontend. Personally I use lirc/irexec to switch between vdr-sxfe and xbmc. The DVD Player button switches to xbmc, and Live TV or Recorded TV for vdr-sxfe. As for startup times, my clients use 28-30W and have no fans or hdd's so I have them on 24/7. At least during Swedish winter a have use for them anyway... /Magnus H ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Are there any guides on how to set up a enviorment like this? regards, lars ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] projects.vdr-developer.org launched
Rolf Ahrenberg wrote: Could you start a new project for ttxtsubs-plugin? The patch is huge and the original plugin author has abandoned the whole VDR thing as far as know. Of course. ttxtsubs hasn't been updated for 4 years. I'll try to get an OK from Ragnar, but will meanwhile create the project. I haven't been keen enough to provide a full changelog for modifications (or even to use the plugin!), but I can dig out contributors from my mail archives if required. Would be nice if you could do this and maybe a short summarization of some important changes. Anyway it could be a good idea to rename somehow these community forks of plugins in order to differentiate them from the original ones: e.g. osdteletext - osdteletextcm, ttxtsubs - ttxtsubscm (cm=community maintained). From a Debian maintainers perspective, I wouldn't like such renamings very much :-) As long as the original author officially released the project (like it was done with OSDTeletext) I would definitly prefer to keep the name. If there would be really a fork, so that there were two different actively maintained development branches, then I would surely follow your suggestion. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Fri, Dec 12, 2008 at 12:30 PM, Halim Sahin halim.sa...@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! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
Udo Richter udo_rich...@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
Re: [vdr] XBMC + VDR 1.7.0
On Fri, Dec 12, 2008 at 11:51 PM, Nicolas Huillard nico...@huillard.net wrote: BoNuZZZ a écrit : Can I start vdr and xineliboutput separately? For example, vdr starts when computer is on, so it works always. But xinelibout is starting when I close xbmc. Yes. You run the plugin in VDR, with no local front-end. You then launch vdr-sxfe (X) or vdr-fbfe (DirectFB) front-end on the machine when you want to display VDR output. VDR runs as a headless daemon. A single vdr-??fe can connect to the xineliboutput plugin at the same time. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I think about using vdr and xineliboutput on the same computer without any tcp connections, but with starting not at once. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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) -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] projects.vdr-developer.org launched
Hello Am Freitag, 12. Dezember 2008 schrieb Tobi: Hello! projects.vdr-developer.org is a place for community maintained VDR projects. The idea for this was born out of a survey conducted among VDR users, where it turned out, that even some VDR plug-ins that haven't been updated for years are still very popular. [...] Read more about this here: http://projects.vdr-developer.org http://projects.vdr-developer.org/wiki/project-management/Start Great to see this announced! Since I support Tobis initiative I decided to host the following two projects on projects.vdr-developer.org too. 1. The vdr-sources git tree (Maintained by skiller2k1 and me) 2. The LIVE plugin git tree (Maintained by Christian Wieninger and me) (*) I think it was a good decision to use git as the central SCM system for this because it supports a patch driven development modell very well. Regards Dieter (Tadi on vdr-portal.de) (*) The old LIVE plugin CVS is still alive, will be updated regularly and will remain at its current hosting. -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
On Sat, Dec 13, 2008 at 12:16 AM, Lars Olsson baronen4...@gmail.com wrote: 2008/12/12 Magnus Hörlin mag...@alefors.se That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I see no reason to use xbmc as vdr frontend. Personally I use lirc/irexec to switch between vdr-sxfe and xbmc. The DVD Player button switches to xbmc, and Live TV or Recorded TV for vdr-sxfe. As for startup times, my clients use 28-30W and have no fans or hdd's so I have them on 24/7. At least during Swedish winter a have use for them anyway... /Magnus H ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Are there any guides on how to set up a enviorment like this? regards, lars ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Yes, xbmc has plugin for using vdr. http://xbmc.org/forum/showthread.php?t=36988 But it has some requiments and limitations and I dont whether it works with hd channels. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
