[vdr] [ANNOUNCE] Frontend for VDR/mplayer on Nokia 770/800
Just some Python I knocked together - don't expect the world. It reads a channel list via SVDRP, shows the list, and launches mplayer with the appropriate arguments. Requires python and mplayer on the Nokia, VDR with streamdev-server and a machine (perhaps the VDR machine) with a CGI-capable webserver (I use thttpd) to transcode from MPEG2 -> low bitrate MPEG4 so the 770 can play it. There's no easy .deb to install - just a tarball, I dunno how to make packages for Maemo yet. Good luck. http://bum.net/vdrview.tar.gz Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] Frontend for VDR/mplayer on Nokia 770/800
On Sun, 2007-08-05 at 22:56 +0200, Thomas Schmidt wrote: > Hi Hi :) > I think that this part is not really required, because the > streamdev-server-plugin (the cvs version since at least may) allready > supports external scripts for transcoding the video-stream. I did consider the Extern support, but this limits the software to running on the same machine as VDR, and I didn't really want to get into a if-then-else construct in describing the setup :) > I would like to help you with improving the program, i can especially > help with creating a Debian package for it. Thanks - I appreciate that :) > I would suggest you to create a project on https://garage.maemo.org/ > there you would have a subversion repository, bugtracker, webspace... > for your project and other people could help you with the program. Hm, I hadn't thought of going that far, to be honest. Primitive though it is, the program fulfils my needs at the moment :) I'll certainly consider it, tho. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Two VDR's on one machine
On Wed, 2008-01-09 at 19:57 +0100, Magnus Hörlin wrote: > other diskless client overloads my network. Therefore I'm interested to > know how hard it would be to modify vdr so I can run one vdr process > with, say /dev/dvb/adapter0-3 and a second one on adapter4? Where do I > start looking? Is it doable? http://linux.die.net/man/8/vdr -D num, --device=num Use only the given DVB device (num = 0, 1, 2...). There may be several -D options (by default all DVB devices will be used). You could also use streamdev-client + server on each instance to allow them to share resources. Not ideal but the best there is currently. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UPnP/DLNA server plugin?
On Thu, 2008-05-01 at 21:20 +0300, Teemu Suikki wrote: > I tried loading streamdev urls like http://vdr:3000/TS/3 with PS3 > browser.. It does understand that it's some sort of stream, but I > think it mistakes it as mp3 audio for some reason. Perhaps it would > help if the url would end with .mpg or something. > I don't have a PS3 - but could you try using URLs with 'PES' or 'PS' in the URL rather than TS? It might like those more :) Especially if it wants '.mpg' extensions, then PS should be exactly what it wants to hear.. Certainly UPnP would be a wonderful goal for streamdev's next development cycle. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tue, 2008-07-22 at 18:37 +0200, Thomas Hilber wrote: > Hi list, > > the last few days I made some interesting experiences with VGA cards I > now want to share with you. Wow! I can't support this project strongly enough - what a perfect idea! In the inevitable shift towards HDTV and progressive scanning, I was becoming increasingly concerned that the countless hours of interlaced content would be forgotten in the scramble for new and shiny. Indeed, my own VDR FF based system exists in a large desktop PC case only because of the enormous (and antiquated) FF card. This project leads the way for replacing it with something much more compact, since the card runs hot and it's only a matter of time before it dies. Is it likely to work with any newer Radeons, or is it because the RV2xx series is the last to have useful full open source drivers? I have a couple of RV3xxs (Radeon X300 + X600 Pro) I'd love to try this with :) Re: http://www.sput.nl/hardware/tv-x.html I've read this page before, and I dearly love the 'Problems' section which I've reproduced verbatim here: "Apparently, some hardware doesn't support interlaced mode. If you have sync problems, check the sync signal with an oscilloscope." Yup, because everyone has one lying around ;) In fact, my biggest problem with this project before now has been the manufacture of such an adapter - my soldering skills are beyond poor. I don't suppose you'd be willing to make some VGA -> SCART hobby-boxes up for a suitable fee? :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tue, 2008-07-22 at 18:37 +0200, Thomas Hilber wrote: > Hi list, > Finally I have had a chance to try these patches - I managed to get an old Radeon 7000 PCI (RV100)... I am using a fresh bare install of Ubuntu hardy which ships xine-lib 1.1.11, but the patches don't compile :( The Makefile.am changed a little but I was able to amend that manually, but the video_out_xv.c spews out this: video_out_xv.c: In function ‘xv_update_frame_format’: video_out_xv.c:475: warning: pointer targets in assignment differ in signedness video_out_xv.c:481: warning: pointer targets in assignment differ in signedness video_out_xv.c:482: warning: pointer targets in assignment differ in signedness video_out_xv.c:483: warning: pointer targets in assignment differ in signedness video_out_xv.c: In function ‘xv_deinterlace_frame’: video_out_xv.c:538: warning: pointer targets in assignment differ in signedness video_out_xv.c:543: warning: pointer targets in passing argument 1 of ‘deinterlace_yuv’ differ in signedness video_out_xv.c:547: warning: pointer targets in assignment differ in signedness video_out_xv.c:552: warning: pointer targets in passing argument 1 of ‘deinterlace_yuv’ differ in signedness video_out_xv.c:566: warning: pointer targets in assignment differ in signedness video_out_xv.c:571: warning: pointer targets in passing argument 1 of ‘deinterlace_yuv’ differ in signedness video_out_xv.c:582: warning: pointer targets in assignment differ in signedness video_out_xv.c:583: warning: pointer targets in assignment differ in signedness video_out_xv.c:590: warning: pointer targets in assignment differ in signedness video_out_xv.c:591: warning: pointer targets in assignment differ in signedness video_out_xv.c:598: warning: pointer targets in assignment differ in signedness video_out_xv.c:599: warning: pointer targets in assignment differ in signedness video_out_xv.c: In function ‘xv_display_frame’: video_out_xv.c:845: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vsync’ video_out_xv.c:845: error: ‘vsync’ undeclared (first use in this function) video_out_xv.c:845: error: (Each undeclared identifier is reported only once video_out_xv.c:845: error: for each function it appears in.) video_out_xv.c:853: error: ‘RADEON_SETPARAM_VBLANK_CRTC’ undeclared (first use in this function) video_out_xv.c:854: error: ‘DRM_RADEON_VBLANK_CRTC1’ undeclared (first use in this function) video_out_xv.c:859: error: ‘DRM_IOCTL_RADEON_VSYNC’ undeclared (first use in this function) video_out_xv.c: In function ‘open_plugin_2’: video_out_xv.c:1769: warning: passing argument 4 of ‘config->register_enum’ from incompatible pointer type make[4]: *** [xineplug_vo_out_xv_la-video_out_xv.lo] I'm no coder so I don't know what I'm looking for.. any advice would be warmly welcomed! Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, 2008-08-12 at 14:01 +0300, Pasi Kärkkäinen wrote: > On Tue, Aug 12, 2008 at 10:29:53AM +0200, Theunis Potgieter wrote: > > Does somebody have a URL on how to make one? for d-sub to scart or the new > > DVI (modern graphic cards) to scart? > > > > http://www.sput.nl/hardware/tv-x.html > > That URL was included in the first mail of this thread.. You can also use this if you have a Radeon and use 'composite' on the modeline instead of '-hsync -vsync' : http://www.idiots.org.uk/vga_rgb_scart/index.html Just please be careful - you can destroy your TV by sending it VGA-spec signals! Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, 2008-08-12 at 14:52 +0300, Pasi Kärkkäinen wrote: > These two links seem to have a bit different ways of doing the cable.. > The first link has more "complicated" cable.. > > Can someone try and compare these or explain the differences? Only Radeons can output a composite sync signal. That's why the second link will only work on Radeons. The simple circuit in the first link merely takes seperate horiz + vertical syncs and combines them into the composite sync required for TV display. As such it will work on any VGA card, but since Thomas' work is restricted to supporting Radeons, there seems little point to make things more complex by building a circuit rather than just a few wires and one resistor :) Note that pin 9 on the Radeon VGA port will provide +5V for you to feed into SCART pin 16 to tell your TV that it's an RGB signal. i.e. you don't need to take a feed from your PC PSU. Cheers, Gavin. Cheers, Gavin, ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, 2008-08-12 at 19:19 +0200, Thomas Hilber wrote: > On Tue, Aug 12, 2008 at 10:29:53AM +0200, Theunis Potgieter wrote: Hi again, Thomas :) I have a system not dissimilar to yours.. it's a P3-1GHz with PCI Radeon 7000. OS is Ubuntu hardy with the patches from your 0.0.2 release. Now that I've got the patches in place, I get a stable desktop display on the TV. If I start vdr / xineliboutput, the picture will be Ok for a second.. then it'll move up and down (like camera wobble, but it moves the onscreen logos / VDR menus, too!). I see this kind of thing at least once per second : [ 2706.402871] [drm] changed radeon drift trim from 00520125 -> 0052018c If I quit vdr (leaving X running), and run the 'drift_control' tool, I see a drift speed of approx -3900 for 4 seconds, then +16000 marked 'excessive drift speed' It's much the same story on the output of the 'startx' console.. lots of <- resyncing field polarity M1 -> and sync point displacement: -365 drift speed: -13004 excessive drift speed overall compensation: -461 every couple of seconds :( The system has no load since it'll become my new VDR box (hopefully :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, 2008-08-13 at 16:39 +0200, Thomas Hilber wrote: 1. for the moment please encomment both in 'radeon_video.c' and 'drift_control' > > //#define RESYNC_FIELD_POLARITY_METHOD1 > //#define RESYNC_FIELD_POLARITY_METHOD2 Done, recompiled + reinstall the .deb, and recompiled the drift_control binary.. > 3. run 'drift_control a' > it is important after some time 'sync point displacement' and 'drift speed' > are floating around zero. overall comp floats -1 to 2, but sync point floats -44 to +45, and drift speed floats -40 to +40. ta absolute + clipped are 5 -> 7. I find it odd that my 'vbls' value is 15500 when yours is 43000.. > 4. stop drift_control > 5. unload all dvb modules (there are known issues with some) I forgot to mention this before - I'm not using any dvb modules - I'm using the streamdev-client to source live TV via HTTP from my live VDR box. I'll have to wait until I can be in front of the machine to try the other tests.. will follow-up then. Many thanks for your time and effort :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, 2008-08-13 at 16:39 +0200, Thomas Hilber wrote:
And now.. part 2 :)
> 4. stop drift_control
> 5. unload all dvb modules (there are known issues with some)
> 6. start vdr with local sxfe frontend (make channels.conf zero size file)
> 7. start replay of some recording. Because field polarity is not synced
> automatically anymore you can manually restart replay until polarity is
> correct.
>
OK, found a suitable recording, and after a couple of 'play 1 begin' to
SVDRP it starts OK. The picture is pretty good, but it still shifts
around the screen a bit:
drift speed:982
overall compensation:30
sync point displacement: 1118
drift speed:422
overall compensation:53
sync point displacement: 64
drift speed: -916
overall compensation: -29
sync point displacement:613
drift speed: -282
overall compensation:11
sync point displacement: -216
drift speed: -369
overall compensation: -20
sync point displacement: -499
drift speed:163
overall compensation: -11
sync point displacement: -685
drift speed:393
overall compensation: -10
sync point displacement: 3175
drift speed: 8509
overall compensation: 402
sync point displacement: 6186
drift speed: -13504 excessive drift speed
overall compensation: -252
sync point displacement: -846
drift speed: -4863
overall compensation: -196
sync point displacement: -430
drift speed: 7566
overall compensation: 246
sync point displacement: -438
drift speed: -8988
So, wow yes it's still all over the place :(
FWIW, the output is not once per second.. there is often a delay of up
to 4 seconds before another group of 3 lines is displayed.
> If the 'drift speed' value finally does show large deviations from zero this
> could be a problem in your xine-lib. In that case I upload my current xine-lib
> version to my web server.
Ouch.
I tried first with the xine-lib 1.11.1 which ships with ubuntu hardy,
and then forward-ported the 1.1.7 packages from gutsy (whilst
repackaging the xineliboutput support for 1.1.7) and had exactly the
same problem. I just find it a bit strange that the same problem should
manifest itself with both an older and a newer xine-lib than you use
(listed as 1.1.8 in your original post)
So, I started looking for other reasons. Whilst X + vdr are running, the
Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU
usage is 32%, with 16% for user processes. I thought maybe it was using
X11 output rather than xv, and thus causing a drain on the system...
I have executed 'xhost +' to eliminate X security issues... and the
syslog shows all positive output:
starting plugin: xineliboutput
Local decoder/display (cXinelibThread) thread started (pid=14236,
tid=14242)
[xine..put] xineliboutput: plugin file
is /usr/lib/vdr/plugins/libvdr-xineliboutput.so.1.6.0
[xine..put] Searching frontend sxfe from /usr/lib/vdr/plugins/
[xine..put]
Probing /usr/lib/vdr/plugins/libxineliboutput-sxfe.so.1.0.0rc2
[xine..put] load_frontend: entry at 0xb569a154
[xine..put] Using frontend sxfe (X11 (sxfe)) from
libxineliboutput-sxfe.so.1.0.0rc2
[xine..put] cXinelibLocal::Action - fe created
[vdr-fe]sxfe_display_open(width=720, height=576, fullscreen=1,
display=:0)
[vdr-fe]Display size : 190 x 152 mm
[vdr-fe] 720 x 576 pixels
[vdr-fe] 96dpi / 96dpi
[vdr-fe]Display ratio: 3789.00/3789.00 = 1.00
[vdr-fe]Failed to open connection to bus: Failed to execute
dbus-launch to autolaunch D-Bus session
[vdr-fe] (ERROR (gnome_screensaver.c,55): Resource temporarily
unavailable)
[xine..put] cXinelibLocal::Action - fe->fe_display_open ok
[xine..put] cXinelibLocal::Action - xine_init
[vdr-fe]fe_xine_init: xine_open_audio_driver("alsa:default") failed
[xine..put] cXinelibLocal::Action - fe->xine_init ok
[xine..put] cXinelibLocal::Action - xine_open
'xvinfo' shows all the good stuff (pages of capabilities), too.
So I'm not entirely sure where to take it from here. Clearly it can
work, but I must be missing a piece..
Sorry - it's a bit of a mixed bag response - I was hoping it would be
much more clear cut!
Cheers,
Gavin.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Thu, 2008-08-14 at 11:25 +0200, Thomas Hilber wrote: Good heavens, this is all getting rather heavyweight :) > oh - a very interesting fact. > that's different to mine (see my output of top below). Xorg takes only 0.7%(!) > CPU on my system. Are there some special patches in ubuntu that causes > this? 1% CPU is about what I would expect for xv usage - after all the whole point is for the app to write directly to video memory with minimal 'processing' A skirt around the problem with Google reveals very little - only a string of users complaining that their silly 3D desktop is slow / unstable (who would have thought? :) > This appears be the root cause of our problem! > > Does the Xserver poll for some resources not available or something? > A value of 40% CPU is way too much. The only process consuming some CPU > power should be 'vdr' whilst decoding. Most other processes don't have > to do much all over the time. It should be said that Xorg is idle when just showing a desktop. It's only when video is played that usage shoots up. > We must dig deeper into that '40% Xserver-CPU' phenomenon! > DISPLAY environment variable is set to DISPLAY=:0 ? Yes. I tried also using mplayer -vo xv /video/bla/12313131/001.vdr and that also generated the same amount of load in Xorg. However, since the PC (Dell Optiplex) has onboard Intel 810 VGA, I removed the radeon and tried it. The same mplayer test yielded only 6% Xorg CPU. Still higher than I would expect, but it was an 800x600 VGA display. Even deleting the xorg.conf and letting the radeon driver choose 'best defaults' I get the 40% CPU load. > You see Xorg is almost not noticable on my system! > > Can you strace the Xserver? Maybe you can try Debian experimental packages > like I do? Don't the run on Ubuntu as well? Well, the Debian experimental packages installed OK, but refused to start: /usr/bin/X11/X: symbol lookup error: /usr/lib/xorg/modules/drivers//radeon_drv.so: undefined symbol: pci_device_map_range giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): unexpected signal 2. (yes, the radeon driver package was upgraded to the experimental one :) and now I am unable to reinstall the ubuntu xorg due to circular dependencies and very strange package behaviour (see [1]), so I've given up on this installation. A shame, since I'd done well and not installed anything into /usr/local this time :) > If it would help you I can offer you to make a copy of my entire development > system (about 800MB as compressed tar image). At this stage that sounds like a good idea. I originally intended to install lenny but the Debian netinst + 'testing2' iso claimed there was no hard disk on the PC (I had the same experience earlier that day with a server at work), so I tried Ubuntu which installed perfectly. Are you suggesting to provide a tarball that I can 'tar xzf' into a freshly-formatted root partition (then run grub) ? Cheers, Gavin. [1] [EMAIL PROTECTED]:~# apt-get install xserver-xorg xserver-xorg-core The following packages have unmet dependencies. xserver-xorg: Depends: x11-xkb-utils but it is not going to be installed PreDepends: x11-common (>= 1:7.3+3) but it is not going to be installed xserver-xorg-core: Depends: libfontenc1 but it is not going to be installed Depends: libxau6 but it is not going to be installed Depends: libxdmcp6 but it is not going to be installed Depends: libxfont1 (>= 1:1.2.9) but it is not going to be installed Depends: x11-common (>= 1:7.0.0) but it is not going to be installed All the Depends: packages are /already/ installed and meet those version requirements! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Thu, 2008-08-14 at 14:22 +0100, Gavin Hamill wrote: > On Thu, 2008-08-14 at 11:25 +0200, Thomas Hilber wrote: > Oh, aptitude solved the dependencies for me (needed to explicitly downgrade one package, then all was well.) Here's the "vmstat 1" output during mplayer playback... i.e. no madness with interrupts / context switching... procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 0 39684 4616 13172 18638000 512 0 259 128 41 31 29 0 1 0 39684 4224 13172 18676400 384 0 252 119 38 31 30 0 2 0 39684 3860 13176 18714400 384 4 262 131 42 30 28 0 1 0 39684 4340 12820 1872280 628 388 628 266 131 40 31 30 0 gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PCI fun (RGB/PAL over VGA at variable frame rate)
Hi all, Over the last days, Thomas and I have been trying to sort out why my nearly-identical machine couldn't run his VGA sync patches properly. The key difference is my Radeon 7000VE is PCI, whilst his is AGP. I tried the PCI Radeon in two old Pentium-3 era machines, and on my modern Pentium D930 desktop, all with the same behaviour - fullscreen video over PCI causes huge CPU usage in the Xorg process, even when using xv 'acceleration'. When I switch the PCI Radeon for a PCI Express X300 (the very lowest 'X' series you can get), everything is glorious: Xorg CPU use is barely 1%. Unfortunately I don't have any machines with both AGP and PCI on which I can try the same OS image but we both think it's safe to conclude that PCI is just unsuitable for this task. Many thanks to Thomas for writing the patches in the first place, and also for the time he's spent logged into my machine remotely trying to solve the problem! Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PCI fun (RGB/PAL over VGA at variable frame rate)
On Sun, 2008-08-17 at 03:41 +0200, Artur Skawina wrote: > PCI in general should be perfectly fine, for SDTV at least. > While displaying SDTV (vdrsxfe) I see ~20% cpu use for X on AGP, ~44% on PCI > (same machine, different heads, AGP is MGA450, PCI is MGA200). Yes, 40% CPU has been what I've seen. The problem is that it's system CPU usage rather than userspace. Due to the critical timing nature of the patches, they need to have nearly the whole machine to themselves, thus DMA PCI overhead causing things to be a 'a bit sticky' is just too much :/ > You could probably do some setpci tweaks to improve PCI throughput, but > I doubt the gain would be enough (I'd expect 10% improvement or so). I did try to twiddle with setting PCI latency timers but it had no measurable effect.. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Sun, 2008-10-05 at 15:10 +0100, Dave P wrote: > A few months ago I posted a VDR patch to implement support for Freeview+, > the cut-down version of TV-Anytime (ETSI TS 102 323) broadcast in the UK. > > I've prepared a new version against VDR 1.6.0-2, and included a simple Perl > script which automatically creates timers for all of the programmes in a > series. Run it overnight as a cron job and never miss your favourite > series again! > > The patch is at http://www.pickles.me.uk/vdrtva-0.0.3.tar.gz Interesting stuff :) I don't suppose it's possible to implement this as a plugin rather than a patch to VDR's core? Is there not enough core exposed via the plugin API? I can't see the patch going into VDR core any time because it's focused squarely at UK users only and Klaus would never have a use for it (unlike the Premiere-specific multi-angle support) so I'm worried that a lot of users will be missing out, especially if they use a packaged VDR. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Tue, 2008-10-07 at 09:14 +0100, Andrew Herron wrote: > I totally agree. LCN's here in the UK and in Australia is central to > ordinary users experience of DVB (aka Freeview here in the UK). At > present we use scan commands -u switch to generate the LCN data. > Having vdr handle this form of channel numbering internally would > seem to be the better option but a plugin would be the next best > option. Users of a single closed system like Freeview, cable, or Sky will certainly be accustomed to preset channel numbers in the EPG - after all Sky et al will be charging different rates to content providers depending on how 'premium' the channel number is.. As a result, in the UK at least, advertising for channels includes the channel number on all three platforms - Freeview, cable and Sky.. Channel numbers might be a novel concept for users of a steerable dish, but for most of us they're utterly standard and quite mandatory for non-technical users. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Tue, 2008-10-07 at 13:48 +0200, Klaus Schmidinger wrote: > On 10/07/08 10:26, Gavin Hamill wrote: > On my Sky digibox "Sky One" is on chanel number 106 - but I never saw > that number in any programme announcement on Sky. The only say "... on Sky > One", > and not "... on channel 106". > > So where exactly are the channel numbers really used? > > BTW: on my VDR the Sky channels start at 201 ;-) Well I can say that poster / magazine advertising in the UK almost always includes the channel number, especially if it's a channel not produced by Sky themselves. Sky One is a special case because it's not carried on Freeview or cable. :) (Our national cable-co refused to pay what Sky demanded for Sky One carriage...) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ITV HD
On Fri, 2008-10-24 at 14:10 +0100, Tony Houghton wrote: > I've read that ITV HD can only be viewd by pressing the red button on a > Freesat receiver. Does this mean VDR can't access it? > It seems very unlikely. Red Button services merely act as a GUI frontend to the raw streams.. e.g. the 'News Multiscreen' support on Freeview was like for ages. There was a MPEG2 stream on one of the BBC's muxes which looked like this | | | | | ### | | ### | | ### | | ### | | ### | | | | | --- Everything was black except for the # areas.. The BBC showed two News24 reels on the right, and BBC Parliament on the left. If you had the correct Vid and Aud PIDs you could see this raw feed. the 'Red Button' stuff just showed graphics to cover up the part you shouldn't have been able to see :) In short, no. Hidden PIDs can be easily found by analysing the bitrates of each PID in a transport stream. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Windows remote client
On Thu, 2008-11-20 at 21:04 +0200, Alex Betis wrote: > > Thanks. Nice project. I'll try to use it, few questions still bother > me. > What is MVP that that client was intended to use? Hauppauge MediaMVP - small hardware device that was supposed to use its own Hauppauge Windows software as its 'server' - the vomp plugins allow VDR to be the server for these devices. > Why creating its own GUI and not pass the output of VDR (with all the > menus) on the network to the client as VLC and streamdev do it? > Maybe the intention was to pass only DVB traffic... The vomp windows client seems to be a software implementation of the MediaMVP hardware, so hence it's using the same protocols :) There is no standard method by which to 'pass all the menus on the network'... > Anyone tried to use the VOMP client as an output device on Linux > instead of xine or softdevice? Yes, works fine. I use it from time to time with a full-featured card. Mainly I just stream a single channel with VLC, tho :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] information about "NO signal"
On Sat, 2009-02-28 at 16:57 +0300, Goga777 wrote: > Hi > > is it possible to implement in VDR the feature as that - > > If there is NOT any LOCK to write about it like "Channel doesn't found" What a great (and obvious!) idea... often I have to use the 'femon' plugin to see if there's a lock, when common behaviour on a commercial STB is indeed to show a 'No signal' message on-sreen. +1 from here. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] More features for Livebuffer
On Mon, 2009-03-02 at 08:18 -0800, VDR User wrote: > On Mon, Mar 2, 2009 at 7:49 AM, Jörg Knitter wrote: > > What about using RAM oder some kind of flash media? > > > > I would really appreciate such a function - as long I can choose where I > > want the buffer to be written... I also would prefer not to have a HD > > recording 24/7... > > Since flash media has a limited amount of writes, I wouldn't recommend > using that as a place to do massive recording. > > I think at the very least the user should have the option to turn > constant hdd recording on/off. I think it's ridiculous MythTV doesn't > allow the user to decide if he wants it and just forces it. Not only > does it create a lot more wear on your hdd, it also keeps your power > usage high and thus your electric bill bigger each month. All that > just so I can rewind live tv any time? Umm, no thanks. There's > nothing that important on tv that I can't find on the net or see again > later when it repeats. ;) My 2c... RAM is cheap - just add some RAM and use a memory-based filesystem like tmpfs? Then there would be no special handling required from VDR since the 'livebuffer' file is part of the directory tree like any other file. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] More features for Livebuffer
On Mon, 2009-03-02 at 19:15 +, Tony Houghton wrote: > On Mon, 02 Mar 2009 19:30:55 +0200 > Rene Hertell wrote: > > > Tony Houghton wrote: > > > On Mon, 2 Mar 2009 08:50:42 -0800 > > > But I wonder, does writing to the HD really shorten its life > > > significantly compared to constant spinning or frequently being spun up > > > and down? > > > > Yes, i guess it does, cause it writes to the hdd:s surface constantly in > > large amounts... > > But there's no physical contact, the surface just has its magnetic > polarity changed (or something like that). Is there a limit to how many > times it can survive those changes? Or perhaps the head moving mechanism > can wear out? > I thought the driving force for having HDs power down was to reduce power, noise and heat? Disk and RAM are both cheap. Take a backup to a giant slow USB disk once a month, etc. :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] HD output - your current favourites
My current vdr-1.4.7 (compiled 2 years ago as of tomorrow!) is still serving me well.. I have a Technotrend FF DVB-C doing all the heavy lifting, but as time moves on and HD content becomes more prevalent, I'm thinking of moving up. Right now I have an EPIA 800MHz quiet PC with the Technotrend giving me lovely SCART RGB out... if I got a nice LCD TV, what setup would be ideal for driving the HDMI input? Most of the content is still SD, and I am a real pedant about smooth video / interlaced output for scrolling text / live sports. Any time that I've played with vdr-xine or xineliboutput over my years with VDR, it's always been a bit juddery due to VGA timing not matching up with the TV.. is that improved any in the world of HD / HDMI? Just interested in hearing your thoughts, since I'm sure there are a dozen different ways to approach this! I can't possibly afford a reelbox at £1100, so if I'm going to do it, I'll have to roll my own :) Cheers, Gavin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD output - your current favourites
On Sat, 2009-08-15 at 14:41 +0300, Pasi Kärkkäinen wrote: > > Take a look at these patches: > > http://lowbyte.de/vga-sync-fields/ > > I believe they are useful also for HDMI/HD stuff. I haven't tried them yet > myself. > :) I'm very familiar with this patches - Thomas and I spent many hours trying to debug a sync problem on an old Dell Optiplex - turned out there was not enough PCI bandwidth, and the machine didn't have an AGP slot.. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Sat, 2009-08-15 at 16:33 +0400, Goga777 wrote: > I'm wondering - does the problem with timing and sync also important and for > for vdpau nvidia cards ? or that project is > important only for intel and ati ? Now that I think about it, I believe this is what I was really asking about.. is it perhaps that good LCD TVs have so much smoothing/deinterlacing processing circuitry that the interlace timing is less of a problem when provided by VGA or HDMI? Progressive content is very difficult to mess up - precious few people could tell the difference between a movie varying between 24 / 25 frames/sec, where it only takes microseconds to cause the interlace fields to jump out of sync. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Sun, 2009-08-16 at 20:16 +0400, Goga777 wrote: > > > for you.. I believe it should be possible to get 50 fps progressive > > > output > > > from 50i material using vdpau deinterlacing. > > yes, my PCI Geforce 8400 card on GPU G98 can do 10...@50 but with the > simplest bob deinterlacing only. I prefer to use > more advanced deinterlacing algorithm - temporal_spatial or temporal. But > with them I have jerky video Hm, do you think you were only able to use simple deinterlacing because of limitations in CPU speed, bus bandwidth (only PCI - I've been thinking about one of the 8400 GSs myself so I can play with it in my PCI-only VDR box..), or power within the G98 GPU itself? > > .. But you might get better results if you outputted 1:1 interlaced material > > using 1080i50 mode and let the LCD tv do the deinterlacing.. > > Yes, exactly what I want to try, But I couldn't run properly 10...@50 - even > in xorg.log I have the report about validated > 10...@50 mode - my LCD TV Philips 9703PFL reported about 1080p source from > hdmi :( Native output and letting the TV do the grunt work would be my prefernece, too - in what way doesn't it work? No output at all or very juddery output ? gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Sun, 2009-08-16 at 22:20 +0400, Goga777 wrote: > I don't know exactly > there's report that on G98 temporal works well. I believe in it > So, I suppose that PCI bus is limited > > nvidia mentioned > http://us.download.nvidia.com/XFree86/Linux-x86/185.18.29/README/appendix-h.html > In order for either VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL or > VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL > to operate correctly, the application must supply at least 2 past and 1 > future fields to each VdpMixerRender call. If > those fields are not provided, the VdpMixer will fall back to bob > de-interlacing. OK yeh the PCI bus, especially with HD content, could fail to supply that amount of raw data. Obviously this is hand-waving since I have no idea of the volumes of data involved :) > I could reach more less good quality output for 10...@50 , but I > decided to come back to 10...@50 because that mode was better than > 10...@50 (I repeat mt TV set always informed me about 1080p mode , > never - about of 1080i) Right, so it could be a problem with the TV set itself - nothing is ever easy! :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Thu, 2009-08-20 at 18:44 +0200, Magnus Hörlin wrote: > Goga777 wrote: > > > Oh no, I will NEVER abandon VDR. I have tried myth twice and I wasn't > impressed. Ah, I have to butt in here with my Myth rant. I too tried Myth, but for me it has a critical flaw -> channel zapping... it takes several seconds to change channel. The myth 'community', aware that it takes many seconds, told me that I am doing it wrong -> the user is supposed to choose something from the programme guide and then switch to it. That alone kills Myth as a TV interface :/ Myth might be pretty to look at, but VDR is super-functional :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Mon, 2009-08-24 at 21:31 +1000, Torgeir Veimo wrote: > 2009/8/24 Seppo Ingalsuo : > > On Mon, 2009-08-24 at 09:12 +1000, Torgeir Veimo wrote: > > > >> > >> Maybe a streamosd plugin could provide what you need. > >> > > > > I can't find further information about that with Google. Is that an > > existing project? > > > > So, I'm not really having problem with VDR's OSD. I just want three > > independent user interfaces to each HTPC/television. > > I was merely suggesting a new type of plugin that allows a remote > client to access and control the osd instance of the vdr server. The > reason this is a problem is that vdr only have the notion of one osd > instance, and streamdev doesn't really provide a way of controlling > this osd. > Yeh, for separate UIs - independent clients, you'd need a single backend which has the DVB cards, and a series of 'frontend' VDRs (even on the same PC) which each export a UI .. and then use streamdev to shuffle video data. I never trusted streamdev as a reliable plugin for a long time, but it now appears to be quite robust and still under active improvement. Of course sharing recordings / timers adds the usual levels of complexity, but I don't forsee VDR becoming a full client/server architecture any time soon so it's likely the best solution for some time.. Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Mon, 2009-08-24 at 14:26 +0200, Theunis Potgieter wrote: > So what happens when the main/server machine gets stuck on channel > zapping, when there and you see only a "no channel" display on the > client? Should the recording happen on the server? or on the client > side? how do you restart vdr if you can't see the server's menu? I didn't say it was either flawless or an ideal approach, but there are always methods by which to deal with such failure. (e.g. the 'remote' plugin can listen on a TCP port and give you text OSD via telnet) IMO, the recordings should always happen on the server. The xbmc-modified streamdev is now able to playback recordings over its own VTP: http://www.xbmc.org/trac/ticket/5595#comment:29 The 'clever stuff' is handling clashes of recordings / timers - some kind of priority system e.g. parents timers override the kids ones. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Sat, 2009-09-05 at 08:18 -0700, VDR User wrote: > On Sat, Sep 5, 2009 at 6:24 AM, Lauri Tischler wrote: > > Somewhat related question is, is there some solution to have > > HD-VDR without X, other than eHD ? > > Not that I'm aware of but by no means have I researched that question > in depth. ;) > > > All this hullaballoo with vdpau/X/xine etc.. is somehow stupid > > if all you want is HD-STB. > > I'm not sure why you think vdpau is stupid if you want an HD stb. > Using vdpau gives you the ability to have HD on systems that normally > wouldn't have a chance at all, and it provides this at a very lost > cost. The cheapest I've paid so far is $20 ($30-$10 MIR) for an > 8400GS pci-e. So for a mere $30 on average, your old system that > couldn't handle HD now can. Stupid is the last thing I would describe > that as. Hm, I'd be happy to pay $150-200 for a hardware output card, similar to the good old FF technotrend cards, if it could save me hours of messing around with SVN bleeding edge code and trying to run exotic deinterlace filters :) I think that's what Lauri is getting at - the statement 'vdpau is stupid' is perhaps a little inflammatory, but there must be more time-efficient ways (other than the eHD card which is now hard to obtain) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] livebuffer patch improvements suggestions.
On Wed, 2009-11-18 at 17:41 +, Scott wrote: > I agree, if the buffer was a configurable FIFO file (location and > size), then the user could choose if the location was on a hard disk > or a RAM disk. I've never used the livebuffer patch - does it add any measurable latency when zapping channels? The last thing I would want is to gradually morph VDR into a sloth like MythTV :( gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] mini-PCIE with Broadcom Crystal HD Hardware Decoder (BCM970012) for HD playback with free drivers
On Tue, 2010-01-05 at 17:29 +, Tony Houghton wrote: > On Tue, 5 Jan 2010 15:01:41 + > Laz wrote: > > The trouble with a purpose-built decoder is that it takes up a valuable > PCI(-E) slot when there are plenty of motherboards with onboard graphics > which should be able to do hardware decoding, even if it does currently > limit the choice to NVidia. In the short term (providing software as > well as drivers supports these cards) a separate decoder has the > advantage that you could pair it with ATI graphics and benefit from FRC > too. > > I think that the future may ultimately lie with OpenCL. The Crystal HD decoder will doubtless appear in netbooks very soon, and I fully expect thin Intel Atom PCs to also feature it on-board. When those boards/machines appear, we will be on the way to a *reliable* open source STB which supports modern HD codecs + playback. As the driver is being taken into the linux mainline kernel, it'll be one less piece of the puzzle to have to checkout nightly SVNs for or rely on a binary blob from NVidia for. That additional choice is surely of great benefit to us all. Maybe then I'll be able to replace my aging FF technotrend card + full-height case :) ... and best of all I'll then be able to justify spending a small fortune on an LCD or Plasma :D gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Play-only client with a FF card or dlink 320rd
On Wed, 2010-01-06 at 17:31 +0100, Travel Factory S.r.l. wrote: > I finally setup a vdr server with a Skystar II and a usb dvb-t stick, running > vdr 1.4.7, display with xine plugin... and probably some minor patches I > don't remember. > > I now need to watch live and/or recorded tv programs on other screens and I > have 2 possibilities: > - dlink dsm-320rd (a uPnP system that is able to replay mpeg2 streams) > - a client vdr with a FF card > > Does anybody know how to setup a working configuration ? Links to howto and > guides are welcome. > http://www.loggytronic.com/vomp.php Comprises a plugin for VDR, a Windows/Linux client and as a firmware for the Hauppauge MediaMVP thin-client device. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Play-only client with a FF card or dlink 320rd
On Wed, 2010-01-06 at 20:27 +0100, Travel Factory S.r.l. wrote: > > > > Comprises a plugin for VDR, a Windows/Linux client and as a firmware > > for > > the Hauppauge MediaMVP thin-client device. > > Hi Gavin, > thank you for your answer. > I own(ed) a Happauge MVP but it is now "lost" somewhere... > > I remember that the MVP uses a custom version of the VNC protocol for the > menu system... I will have a look if the media transport is compatible. No need - the VOMP package includes a software for the MediaMVP which completely replaces the one written by Hauppauge ... the MediaMVP still boots off the network but it no longer requires the Hauppauge Windows software. You are right, it's all done using a little tweaked version of VNC :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 1.7.12 w/ FF card on old Linux + S2API wrapper
I've been using the same 1.4.7 setup for over 2 years and thought I'd
dip my toe in the 1.7.x world. I'm using Ubuntu dapper (mid 2006) so my
DVB kernel/header setup is still at API level 3, hence I've been using
Udo Richter's S2API wrapper.
Compile was ok, but even trying the simplest setup of "./vdr
-Pdvbsddevice" I'm unable to get a picture or OSD through the FF card.
Is this supposed to work with the S2API patches, or are those purely for
input only?
Jan 31 16:59:01 telly vdr: [10843] VDR version 1.7.12 started
Jan 31 16:59:01 telly vdr: [10843] codeset is 'UTF-8' - known
Jan 31 16:59:01 telly vdr: [10843] found 25 locales in ./locale
Jan 31 16:59:01 telly vdr: [10843] loading
plugin: ./PLUGINS/lib/libvdr-dvbsddevice.so.1.7.12
Jan 31 16:59:01 telly vdr: [10843] loading /video/setup.conf
Jan 31 16:59:01 telly vdr: [10843] loading /video/sources.conf
Jan 31 16:59:01 telly vdr: [10843] loading /video/channels.conf
Jan 31 16:59:01 telly vdr: [10843] loading /video/timers.conf
Jan 31 16:59:01 telly vdr: [10843] loading /video/svdrphosts.conf
Jan 31 16:59:01 telly vdr: [10843] loading /video/remote.conf
Jan 31 16:59:01 telly vdr: [10843] loading /video/keymacros.conf
Jan 31 16:59:01 telly vdr: [10843] ERROR: unknown plugin 'screenshot'
Jan 31 16:59:01 telly vdr: [10843] ERROR: empty key macro
Jan 31 16:59:02 telly vdr: [10843] reading EPG data from /video/epg.data
Jan 31 16:59:02 telly vdr: [10844] video directory scanner thread
started (pid=10843, tid=10844)
Jan 31 16:59:02 telly vdr: [10845] video directory scanner thread
started (pid=10843, tid=10845)
Jan 31 16:59:02 telly vdr: [10844] video directory scanner thread ended
(pid=10843, tid=10844)
Jan 31 16:59:02 telly vdr: [10845] video directory scanner thread ended
(pid=10843, tid=10845)
Jan 31 16:59:03 telly vdr: [10843] probing /dev/dvb/adapter0/frontend0
Jan 31 16:59:03 telly vdr: [10843] creating cDvbDevice
Jan 31 16:59:03 telly vdr: [10843] new device number 1
Jan 31 16:59:03 telly vdr: [10843] frontend 0/0 provides DVB-T
("Conexant CX22702 DVB-T")
Jan 31 16:59:03 telly vdr: [10843] probing /dev/dvb/adapter1/frontend0
Jan 31 16:59:03 telly vdr: [10843] creating cDvbDevice
Jan 31 16:59:03 telly vdr: [10843] new device number 2
Jan 31 16:59:03 telly vdr: [10847] tuner on frontend 0/0 thread started
(pid=10843, tid=10847)
Jan 31 16:59:03 telly vdr: [10848] section handler thread started
(pid=10843, tid=10848)
Jan 31 16:59:03 telly vdr: [10843] frontend 1/0 provides DVB-C ("VLSI
VES1820 DVB-C")
Jan 31 16:59:03 telly vdr: [10843] found 2 DVB devices
Jan 31 16:59:03 telly vdr: [10843] initializing plugin: dvbsddevice
(0.0.3): SD Full Featured DVB device
Jan 31 16:59:03 telly vdr: [10843] setting primary device to 2
Jan 31 16:59:03 telly vdr: [10843] device 2 has no MPEG decoder
Of course, device 2 VLSI VES1820 DVB-C definitely does have an MPEG
decoder? Do I really need to upgrade the OS to use newer VDR?
I tried both the existing dvb-ttpci-01.fw and the new TS-enabled one,
with the same results.
Cheers,
Gavin.
[1] http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.7.12 w/ FF card on old Linux + S2API wrapper
On Sun, 2010-01-31 at 15:29 -0800, VDR User wrote: > If you're using a v4l tree that works with both your kernel and the > S2API wrapper, then you may want to try a VDR version prior to the FF > specific stuff being moved into a plugin and see if you have any > better luck. I could be wrong but I think the FF change may not be > 100% yet. Hm, 1.7.10 showed greater success (i.e. last version before dvbsddevice) ... the DVB-C FF worked fine - video and OSD rendered OK, but the DVB-T card than refused to tune to anything at all. Ah well, 1.4.7 works OK for me so I'll just hang on until I can justify updating the entire setup for HDMI. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] streamdev CVS - recent tarball?
Hi, I'm trying to compile streamdev 0.5.0 on an elderly 2006 Ubuntu and am getting some compile errors. Frank Schmirler says the current CVS contains fixes for that, but the CVS server at vdr-developer.org is down. Does anyone have a recent CVS checkout they wouldn't mind sending me? streamdev is the last thing I need to finally upgrade from VDR 1.4.7 :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] channels.conf for Sky UK ?
Does anyone have a reasonably recent channels.conf for Sky in the UK that they wouldn't mind sharing - it'd save me from a couple of very dull hours! Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] channels.conf for Sky UK ?
:) It was precisely the numbering/grouping I was after - at the moment I have the similar output from 'scan' but was hoping to avoid cut/paste pain... Thanks anyway - that site is a good resource. gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev CVS - recent tarball?
Thanks to Frank for updating the tarball on http://vdr.schmirler.de/ :) It compiles and loads cleanly on my VDR 1.6.0 system - I can see the new HTTP menu with javascript categories (nice! :) but the basic feature of streaming via HTTP fails. I have moved the streamdevhosts.conf into /video/plugins/streamdev-server but even when I launch a simple # curl http://localhost:82/101 ... I get no data returned :( The logs don't say much: Sep 20 10:56:19 telly vdr: [10118] Streamdev: Accepted new client (HTTP) 127.0.0.1:3128 Sep 20 10:56:28 telly vdr: [10118] client (HTTP) 127.0.0.1:3128 has closed connection Sep 20 10:56:28 telly vdr: [10118] streamdev: closing streamdev connection to 127.0.0.1:3128 Sep 20 10:56:28 telly vdr: [10118] buffer stats: 0 (0%) used This is vanilla 1.6.0 with the -1 + -2 patches applied, but nothing else. Commandline is just "./vdr -Pskinsoppalusikka -Pstreamdev-server" Any ideas warmly received :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev CVS - recent tarball?
Ah, it does work, but only if I use http://hostname:port/TS/. PES/PS/ES do not work. I'm not bothered too much about PES/PS but ES is very useful for streaming radio. How can I help to debug this further? gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ProjectX and burn plugin
I'm posting this here for the lack of a better place. The ProjectX home page is a German-only forum, and as I don't speak German, that leaves me a little stuck. Basically, ProjectX 0.90.4 barfs as part of the burn plugin 0.1.0-pre20's work when I have a recording with 'Audio Description' soundtrack (a 64kbit mono mp2 track intended for blind people to describe what is happening on-screen). It's a bit annoying, since I don't even want this soundtrack included in the recording.. [demux] + /usr/bin/java -Djava.awt.headless=true -jar /usr/local/projectx/ProjectX.jar -ini /video/plugins/burn/ProjectX.ini -cut /video/.vdr-burn.Hmcv14/VDRSYNC.0/px.cut -id 0xe0,0xc0,0xc1,0x1f,0x20 -demux -out /video/.vdr-burn.Hmcv14/VDRSYNC.0 -name vdrsync /tmp/.vdr-burn.gzXBn0/VDRSYNC.0/convert/001.vdr demuxes the video 0xe0 fine, the first audio track 0xc0 fine, and then bails out on 0xc1: [demux] --> MPEG Audio (0xC1) [demux] check & synchronize audio file vdrsync[1].mp [demux] [demux] 1 %-> check CRC of AC-3 / MPEG-Audio L1,2 [demux] -> delete CRC in MPEG-Audio Layer1,2 [demux] -> add frames [demux] Audio PTS: first packet 01:20:56.853, last packet 01:50:10.600 [demux] Video PTS: start 1.GOP 01:20:56.653, end last GOP 01:50:10.013 [demux] -> adjusting audio at video-timeline [demux] !> 8 frame(s) (192ms) pre-inserted @ 00:00:00.000 [demux] -> src_audio: MPEG-1, Layer2, 48000Hz, mono, 64kbps, CRC @ 00:00:00.192 [demux] !> 2 frame(s) (48ms) inserted @ 00:00:17.448 [demux] [demux] 2 % [demux] 3 % [demux] 4 %!> 2 frame(s) (48ms) inserted @ 00:00:53.448 [demux] [demux] 5 % [demux] 6 %!> 2 frame(s) (48ms) inserted @ 00:01:31.368 [demux] [demux] 7 % [demux] 8 %!> 2 frame(s) (48ms) inserted @ 00:02:07.368 [demux] [demux] 9 % [demux] 10 %!> 2 frame(s) (48ms) inserted @ 00:02:45.288 [demux] [demux] 11 % [demux] 12 %!> 3 frame(s) (72ms) inserted @ 00:03:22.512 [demux] [demux] 13 % [demux] 14 %!> 3 frame(s) (72ms) inserted @ 00:03:58.512 [demux] [demux] 15 % [demux] 16 %!> skipped sourceframe(s) @ 00:04:32.376 [demux] !> 2 frame(s) (48ms) inserted @ 00:04:36.432 [demux] [demux] 17 % [demux] 18 %!> 2 frame(s) (48ms) inserted @ 00:05:12.432 [demux] [demux] 19 %stopped... [demux] [demux] !> an error has occured.. (please inform the authors at 'forum.dvbtechnics.info') [demux] java.lang.ArrayIndexOutOfBoundsException: -1 [demux] at net.sourceforge.dvb.projectx.audio.AudioFormatMPA.decodeAncillaryData (Unknown Source) [demux] at net.sourceforge.dvb.projectx.audio.AudioFormat.decodeAncillaryData (Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamProcessAudio.processAudio (Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamProcessAudio.processStream (Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamProcessAudio.(Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamProcess.process(Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamProcess.(Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamParserPESPrimary.parseStream (Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.StreamParser.parseStream(Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.MainProcess.processCollection (Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.MainProcess.startProcessing(Unknown Source) [demux] at net.sourceforge.dvb.projectx.parser.MainProcess.run(Unknown Source) [demux] [demux] -> we have 13 warnings/errors. Ouch! :) I've put the complete logfile up at http://bum.net/dvd.log - I can make all of the source files available too (about 1GB) if they'll help some kind soul? :) Cheers, Gavin. [1] Sascha is still working on the burn plugin at http://www.magoa.net/linux/contrib/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ProjectX and burn plugin
On Wed, 16 Aug 2006 19:38:20 +0300 "Petri Helin" <[EMAIL PROTECTED]> wrote: > You might as well try your luck at the ProjectX forum. Although most > of the messages there are german, at least I have always gotten an > answer in english if the question was in english. dvb.matt responds > quite rapidly so I recommend you try it out. Thanks - I'll give that a go :) It's fortunate that every forum works the same, and I can at least navigate by watching the URL + .php script names :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ProjectX and burn plugin
On Sun, 20 Aug 2006 15:59:21 +0200 Steffen Barszus <[EMAIL PROTECTED]> wrote: > For the time being, you should also be able to deselect the audio > track. If you have selected the recording, change to the list of > recordings to be burned and hit ok, while you are at the recording > there. You will get the list of audiotracks and you can resort , > deactivate them as you like. > > Hope that helps in the meantime :) Wow you learn something new every day - I'll have to give that a whirl since I don't want those extra soundtracks anyway :) For reference... dvb.matt (author of ProjectX) did write back and advised me to include this line to /video/plugins/burn/ProjectX.ini MessagePanel.logRDS=0 Now although I get a whole load of warnings in the log, the authoring process completes OK and I get an ISO that burns + plays just fine :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Freecom DVB-T stick - can't open filter handle on demux0
Just a bit of a nudge - I thought I'd try this again with a newer kernel and VDR (2.6.17 in Ubuntu edgy and VDR 1.4.4) in case something small and subtle had been fixed. Alas no, the original problem still stands as-is: http://www.linuxtv.org/pipermail/vdr/2006-July/010115.html I've made an even more rudimentary setup of vanilla VDR + skincurses plugin. No FF card, no output devices.. just a curses console and I still regularly get Nov 27 22:26:26 plip vdr: [10131] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0' on channel changes - `lsof -n | grep demux` still shows only 8 or 9 file descriptors open :( A shame, I'd love to have VDR working with this device - does anyone have any advice, since it works just great in Kaffeine! Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdradmin: can't "watch tv"
On Monday 04 December 2006 13:14, Suur Karu wrote: > Installed vdradmin-am-3.5.1 give me strange TV picture on "Watch TV" menu: > http://kodu.neti.ee/~pa000t/files/vdradmin.gif > > make.sh check said that all Perl modules presents. > Using Slackware 11.0 (2.6.18 kernel) with 2 budget cards. VDRAdmin's 'watch TV' feature only works with Full-feature cards. It uses VDR's 'GRAB' command via SVDRP to take a snapshot from the /dev/videoN v4l device... Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamplayer - no audio when streaming audio only?
On Wed, 10 Jan 2007 16:19:29 +0100 [EMAIL PROTECTED] (Lars Fredriksson) wrote: > Is there anyone who has a clue about whi it isn't working - is it > because there is no video? Yes. Using 0.1.3 from the Udo's homepage shows this in the README: -- Future Plans -- This is no promise, just a white board of things that sound nice. No guarantee whether and when this will happen... -Deleting/moving bookmarks -RTP/RTSP protocol for real video-on-demand -PS/PES stream formats -Improved PID detection, read PAT tables etc. -Dynamic PID changes while running? -Support pure audio streams -Support multiple audio streams -- So, looks like you'll need to get VLC to encode a video stream, even if it's just black :) Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Same Channel from DVB-C, DVB-T and channels.conf
On Saturday 03 February 2007 13:16, Tommi Lundell wrote: > Hello > > I'm cannot find information how i can tell to vdr that example following > channels are one and same. (Is that even possible?) I've often wondered this and have posted about 'logical channels' here a couple of times... however, this might be useful for you: http://www.linuxtv.org/pipermail/vdr/2006-August/010324.html gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK Freeview Logical Channel Numbers
Andrew Herron wrote: Does anyone know if the Logical Channel Numbers that are used in the UK on Freeview DVB-T transmissions are currently handled by VDR in anyway? I can tell you for certain that they are not handled. :) There is code in the standalone dvb-apps 'scan' application to parse Freeview LCNs, but that's it... Cheers, Gavin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
Carlos Javier Borroto wrote: On 2/19/07, Kartsa <[EMAIL PROTECTED]> wrote: I was about to test the performance of vdr when I stumbled on this message ERROR: /dev/dvb/adapter0/demux0: Too many open files I'm also having this error, only in my case, is not only related to recording, it also happens sometimes when just changing the channel: What hardware are you using? I mean, what driver is being used? Is it dvb-usb-dtt200u ? If so.. 'me too' :) http://www.linuxtv.org/pipermail/vdr/2006-June/009718.html I never found a solution, so bought different hardware :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
