Re: [vdr] Which extension for TS files?
On Sunday 04 January 2009, Vladimir Kangin wrote: You right. For example I'm keen of LinuxMCE (www.linuxmce.org) and it has a script that looking for media files, thus all .vdr are recognised as a video files of VDR while is not. It would would be a very wise step to improve this at the same time... Without knowing a thing about LinuxMCE, I suppose its scripts could be improved to only look for numbers.vdr. For example, if it uses find(1), instead of find /some/dir -name '*.vdr' ...it could do: find /some/dir -regex '.*/[0-9]+\.vdr' ...or if -regex is a problem, perhaps even simply this would be an improvement over '*.vdr': find /some/dir -name '???.vdr' (This is not in any way an objection to the renaming plans discussed here lately, the outcome of that seems good to me.) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
On Tue, Jan 06, 2009 at 01:17:52AM +0200, Jukka Vaisanen wrote: Yes, it's a good idea to get 1:1 pixel mapping on your display. Double scaling (first pc, then display) is not a good idea, ever. But, some problems arise: HDMI uses DVI signalling for the video (and audio is hidden in a vertical blanking time slot believe it or not) so it may seem like just another connector.. however in their finite wisdom the HDMI standardization people decided that HDMI will not support arbitrary resolutions, but instead only the existing (and back then, planned) broadcast resolutions: - 576i/p (pal) and 480i/p (ntsc) - 720p (1280x720) - 1080i and 1080p (1920x1080) The world is full of TVs with 1366x768 and other weird resolutions. There are also plasmas with 1024x768 etc standard computer resolutions. The big surprise to many people is that even though DVI signalling could carry these native resolutions, the displays themselves won't accept / sync to them. And they don't advertise them in the EDID data so you have to force your computer to that resolution / refresh to even try it (and fail). The only true 720p displays I have seen are rear-projection TVs and data/av projectors. They will accept their native resolution of 1280x720 over HDMI, however getting rid of overscan to get 1:1 is another matter.. Then a solution: I used to have a Panasonic plasma with a similar non-standard resolution and I used the VGA port with it to automatically get a 1:1 pixel display as it's intended for PC display use. Yes VGA is not optimal but at that resolution and a 1 meter cable, who cares... Today I have a full HD 1920x1080 panel with an option for exact scan which gives me 1:1 pixels (without overscan) out of the box over HDMI, I just run normal 1920x1...@60hz out of my computers. And finally a question: If someone can tell me how to get 576i over HDMI out from VDR, please do. That way I could use my external HQV Reon video scaler to upscale it.. Of course it would need to allow me to switch modes for 720p and 1080i also based on broadcast resolution ;) Hello. Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html Original patches: http://lowbyte.de/vga-sync-fields/ New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that.. There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which extension for TS files?
Hi guys, Klaus wrote: I've already dropped them. Besides, these files are just auxiliary internal files for VDR's very own purposes. There should normally be no need to edit them at all. I'm writing from work (webmail), so sorry if the email format gets fudged up. I never really liked the name all files .vdr terminology. However, totally dropping them is an EQUALLY bad idea, since, unlike Linux, Windows programs depend on the extension for association. I would like to propose using the following: Video / Audio container files: xyz.ts Index files: index.vdr Info files: info.txt Cutter marks: marks.dat Resume files: resume.vdr or resume.dat Klaus says there is no need to edit them (not quite true ;o)), but I would like at least to be able to read them easily. Here are my reasons for asking this: xyz.ts: Sometimes it is nice to able to edit or even just watching them externally. With an extension that is common to all video editors or players, it makes it much easier. index.vdr: Index contains no valuable info for external programs and it doesn't need editing, so we can leave this or even remove the extension all together. Info.txt: The info file esp. is a good thing to have since you can simply copy the info on a Windows PC (for title or contents) when burn them to a CD or DVD. It saves time, just being able to copy and paste via keyboard. If I have to tell the program to open with and associate a programm EVERY time I burn a video file to DVD it becomes much too time consuming. Marks.dat: To me it has happend a couple of times (esp if vdr runs out of disk space) that you are not able to jump forward or backward in a video file or even move the placed marks. Being able to edit the marks file or even deleting the preset times makes it easy to correct this problem. I can either place the marks where I need them (if known) or delete all of them if the video file is totally unresponsive. Resume files: resume.vdr or resume.dat: I don't use this file, so to me it makes no difference what is done with the extension. However, for others, esp. multi-user VDR setups it might be handy to able to edit these (making the .vdr a better decision to be able to differiantiate it from the marks.dat file) any extension at all. If they are in a .rec-directory it should be pretty clear what a file named index contains. Not quite sure who wrote this, but this argument isn't vaild, since external editors or programs have no knowledge of VDR's data structure or hierarchy. Naming (or just deleting ;o)) all the extensions the same doesn't change the situation. kind regards, Reinhard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
I don't know how to do the latter, and even if it is possible in all cases. In my setup, I have set up my video card to 1:1 to the panel I have (fullHD), since I have material in several different resolutions, This is the theory. But you need to remember that you are using TV set as a monitor, and typical TV sets, even FullHD ones implement overscan on HDMI input. Some TVs disable overscan via special switch. But having overscan it means that having the 1:1 mapping is a bit harder. You need to find out how much is the real visible resolution and define X- screen to that resolution. Naturally way to determine this is to have test patterns drawn to a screen and look closely (mag. glass) to see if you have 1:1 mapping. You need to remember that HDMI/DVI is not a digital bus, it is 'analogue'-type signal transferred in digital fashion. Why else you need porches et al at signal timing? With this I mean that HDMI-signal does not say: -frame coming at resolution 1920x1080p50 -pixel at 0,0 use color 0,0,0 -pixel at 1,0 use color 255,255,255 -pixel at 2,0 use color 0,0,0 ... HDMI says: - vert. sync - hor. sync - front porch time - (0,0,0),(255,255,255),(0,0,0),. And it is up to TV electronics where to place those pixels on LCD panel. And this is done with overscan settings etc. - Jori winmail.dat___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ANNOUNCE vdr-ttxtsubs 0.0.8
Antti Hartikainen wrote: Solution so far has been to use little transparent background, but it looks ugly, not like normal text should look like (white text with few pixels thick black border) I think VDR doesn't support drawing an outlined OSD text. The only way to do this, might be to render the text to a bitmap and show the bitmap instead. Maybe this would be a good opportunity to somehow transform ttxtsubs to dvb subs which then can be handled by VDR itself. Any suggestions or contributions are welcome. Use the force / issue tracker Luke! :-) http://projects.vdr-developer.org/projects/plg-ttxtsubs/issues Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
Jukka Vaisanen wrote: HDMI uses DVI signalling for the video (and audio is hidden in a vertical blanking time slot believe it or not) so it may seem like just another connector.. however in their finite wisdom the HDMI standardization people decided that HDMI will not support arbitrary resolutions, but instead only the existing (and back then, planned) broadcast resolutions: HDMI interface does not limit the resolutions (TMDS link max. speed of course does but is another matter). It's mostly the HD Ready and Full HD television implementations that support only CEA-861-D modes for HDTV. Nothing would prevent HDTVs to introduce other modes in EDID and EDID extension blocks similarly as DVI computer monitors do. Though the timings would need be defined in such way that there is space for audio. Fortunately full HD televisions typically support 1:1 pixels over HDMI so the limited amount of modes is not that bad. GFX cards will scale other resolutions such as 800x600 and 1024x768 VESA modes into the native panel resolution. My 2c: I'm watching also a HD ready television from 2005 and despite of 2x scaling the difference with DVB PAL content is minimal to my other full HD television with only one scaling operation. The quality of the SDTV DVB-T/S content is IMHO the bottleneck instead of video scalers. Also non 1:1 pixels Gnome desktop is usable. Of course 1 pixel wide too small fonts must be avoided. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
On Tue, 06 Jan 2009 09:12:04 +0200 Pasi Juppo p...@juppo.fi wrote: I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it. Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
On Tue, 6 Jan 2009 02:23:51 +0200 Jukka Vaisanen jukka.vaisa...@exomi.com wrote: 24p is just a framerate, in HD it's actually 1080p but with 24 frames per second instead of 60. There are also NTSC DVDs with 24p video but that's a whole different story that we won't get into.. Yes, I know, but what's the difference between a TV and DVD/Blu Ray player that claims to support it and one that doesn't? I'm guessing there's an extra screen mode available at 24/48/72Hz. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it. Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day. At least for now it seems to use vdr as a backend. Has anybody tested it. Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
2009/1/6 jori.hamalai...@teliasonera.com: I don't know how to do the latter, and even if it is possible in all cases. In my setup, I have set up my video card to 1:1 to the panel I have (fullHD), since I have material in several different resolutions, This is the theory. But you need to remember that you are using TV set as a monitor, and typical TV sets, even FullHD ones implement overscan on HDMI input. Some TVs disable overscan via special switch. Yes, you are right. On my Sony it is called Täyskuiva (in finnish), when I had not enabled it, thie TV did overscan IIRC. But having overscan it means that having the 1:1 mapping is a bit harder. You need to find out how much is the real visible resolution and define X- screen to that resolution. I'm not sure what you mean by the above, surely you need to setup X to use the native resolution of the panel? Perhas you meant something different, as I did notice when I did my setup; that fgrlx (yuch, I'm an user of the dreadful fglrx) does a terrible underscan by default, becase it reports a larger screen area trough the HDMI that is actually used (?). I'd assume that nvidia, intel perhaps some others do this better by default. It is beyond me why an ouput that is used for a digital display uses any kind of over/underscan, but that really was the case. Then I stumbled on this: http://www.phoronix.com/forums/showthread.php?p=36734#post36734 And got 1:1 mapping at all refresh rates ever since. Thoguh, I still get terrible tearing - I've heard that the radeon driver should be better in video use, but I couldn't get it to work on my card, and I also need DRI... I should've bought nvidia, damn. I used a small program called lcdtest to test the 1:1 mapping. Believe when I say you do notice the difference =). Also I use a desktop and it is drawn exactly to the edges as it should be. -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
On Tue, 6 Jan 2009 04:29:55 + Scott sc...@waye.co.uk wrote: As Im just starting to get vdr working, I was wondering if 1:1 pixel mapping between the video card (nvidia onboard HDMI output) and my flat panel (Samsung plasma) is a waste of time. When looking at a computer generated image like the desktop, its going to make a difference, but with broadcast material (SD mostly), I imagine that the material is scaled anyway to fit the resolution of the panel (which in my case I think is 1024x720, but that has a bit of overscan). So it wont be 1:1 anyway, or am I wrong here?I know this is a bit off topic, but there seems to be a fair bit of experience here. With my TV I've tried running vdr-sxfe at 1360x...@60 (which the TV does accept over HDMI, but not VGA), 1280x...@50 and 720x...@50. Surprisingly 720x576 seems to look a bit rougher to me than the other two resolutions. I find 1280x720 is slightly better than 1360x768 for VDR because of the matching refresh rate. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.3
VDR developer version 1.7.3 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.3.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.2-1.7.3.diff WARNING: This is a *developer* version. Not even *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The main focus of this version is the switch to Transport Stream (TS) as the recording format. There are still a few glitches, mainly - Recording/replaying of pure audio broadcasts doesn't work yet. - Recording files larger than 4GB or with more than 255 separate files hasn't been tested yet. - Recording h.264 broadcasts has been roughly verified to work, but no replaying of such recordings has been tested yet. - There is apparently still a problem with editing old PES recordings. An edited recording is created, but it doesn't play. DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!! THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT WORK WITH FUTURE VERSIONS! Despite this, I do hope there will be some people who can take a look at the changes and maybe test the new recording format - and report bugs or provide fixes ,-) The changes since version 1.7.2: - Updated the Russian OSD texts (thanks to Oleg Roitburd). - Fixed handling the 'pointer field' in generating and parsing PAT/PMT (thanks to Frank Schmirler). - Fixed handling modulation types for DVB-S transponders when processing the NIT. - Changed cDvbDevice::GrabImage() to use V4L2 (thanks to Marco Schlüßler). - Added a poll to cDvbDevice::PlayVideo() and cDvbDevice::PlayAudio() to avoid excessive CPU load (this is just a makeshift solution until the FF DVB cards can play TS directly). - The recording format is now Transport Stream. Existing recordings in PES format can still be replayed and edited, but new recordings are done in TS. All code for recording in PES has been removed. The following changes were made to switch to TS recording format: + The index file format has been changed to support file sizes of up to 1TB (previously 2GB), and up to 65535 separate files per recording (previously 255). + The recording file names are now of the form 1.ts (previously 001.vdr). + The frame rate is now detected by looking at two subsequent PTS values. The frame duration (in multiples of 1/9) is stored in the info.vdr file using the new tag F (thanks to Artur Skawina for helping to get the IndexToHMSF() calculation right). + Several functions now have an additional parameter FramesPerSecond. + Several functions now have an additional parameter IsPesRecording. + The functionality of cFileWriter was moved into cRecorder, and cRemux is now obsolete. This also avoids one level of data copying while recording. + cRemux, cRingBufferLinearPes, cTS2PES and all c*Repacker classes have been removed. + A PAT/PMT is inserted before every independent frame, so that no extra measures need to be taken when editing a recording. + The directory name for a recording has been changed from -MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to -MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resumeId). Priority and Lifetime are now stored in the info.vdr file with the new tags P and L (if no such file exists, the maximum values are assumed by default, which avoids inadvertently deleting a recording if disk space is low). No longer storing Priority and Lifetime in the directory name avoids starting a new recording if one of these is changed in the timer and the recording is re-started for some reason. Instead of Priority and Lifetime, the directory name now contains the channel number from which the recording was made, and the resume id of this instance of VDR. This avoids problems if several VDR instances record the same show on different channels, or even on the same channel. The '-' between channel number and resumeId prevents older versions of VDR from seeing these recordings, which makes sure they won't even try to replay them, or remove them in case the disk runs full. + The semantics of PlayTs*() have been changed. These functions are now required to return the given Length (which is TS_SIZE) if they have processed the TS packet. + The files index, info, marks and resume within a TS recording directory are now created without the .vdr extension. + The resume file is no longer a binary file, but contains tagged lines to be able to store additional information, like the selected audio or subtitle track. + cDevice::StillPicture() will now be called with either TS or PES data. + cDvbPlayer::Goto() no longer appends a sequence end code to the data. If the output device needs this, it has to take care of it by itself. - Fixed
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
On Tue, 6 Jan 2009, Klaus Schmidinger wrote: - cDvbDevice now uses the FE_CAN_2G_MODULATION flag to determine whether a device can handle DVB-S2. The #define is still there to allow people with older drivers who don't need DVB-S2 to use this version without pathcing. Sorry for hijacking the thread, but you forgot to rename the old #define. Check the attached patch. BR, -- rofadiff -Nru vdr-1.7.3-vanilla/dvbdevice.c vdr-1.7.3-dvbdevice/dvbdevice.c --- vdr-1.7.3-vanilla/dvbdevice.c 2009-01-06 18:12:44.0 +0200 +++ vdr-1.7.3-dvbdevice/dvbdevice.c 2009-01-06 18:28:21.0 +0200 @@ -32,7 +32,7 @@ // unpatched driver. However, with an unpatched driver it will not support // DVB-S2 hardware. If you have DVB-S2 hardware you need to either patch // the driver or modify the line that uses this macro in cDvbDevice::cDvbDevice(). -#define FE_CAN_2ND_GEN_MODULATION 0x1000 +#define FE_CAN_2G_MODULATION 0x1000 #define DO_REC_AND_PLAY_ON_PRIMARY_DEVICE 1 #define DO_MULTIPLE_RECORDINGS 1 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
On 06.01.2009 17:32, Rolf Ahrenberg wrote: On Tue, 6 Jan 2009, Klaus Schmidinger wrote: - cDvbDevice now uses the FE_CAN_2G_MODULATION flag to determine whether a device can handle DVB-S2. The #define is still there to allow people with older drivers who don't need DVB-S2 to use this version without pathcing. Sorry for hijacking the thread, but you forgot to rename the old #define. Check the attached patch. Sorry about that. Originally I had totally deleted that, but then decided to leave it in for convenience - and just copied the original back without changing it. I guess I'll totally delete it, since this is now in the driver, anyway. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
On Tue, 6 Jan 2009 16:47:35 +0200 (EET) Mika Laitio lam...@pilppa.org wrote: I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it. Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day. At least for now it seems to use vdr as a backend. Has anybody tested it. I should let on that I'm the developer and I've been using it a lot. I started writing it back before VDR had a media player, so some sort of frontend was really needed; even now I think boxstar has a lot of advantages over VDR's media player, but VDR, especially with the xineliboutput plugin, did improve a lot so I wasn't motivated to develop boxstar's own DVB support. Now I've got a DVB-S card and a DVB-T card together, VDR's channels management just isn't good enough, so because of all sorts of other niggles and because I don't like C++ enough to make big changes to VDR I want to press ahead again with boxstar's DVB support. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
Tony Houghton wrote: On Tue, 06 Jan 2009 09:12:04 +0200 Pasi Juppo p...@juppo.fi wrote: I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it. Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day. Yes, that's what I meant but wrote something else :-) I sure wish the best for the developer(s) - it surely is not a small task. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates?
Tony Houghton wrote: On Tue, 6 Jan 2009 16:47:35 +0200 (EET) Mika Laitio lam...@pilppa.org wrote: I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it. Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day. At least for now it seems to use vdr as a backend. Has anybody tested it. I should let on that I'm the developer and I've been using it a lot. I started writing it back before VDR had a media player, so some sort of frontend was really needed; even now I think boxstar has a lot of advantages over VDR's media player, but VDR, especially with the xineliboutput plugin, did improve a lot so I wasn't motivated to develop boxstar's own DVB support. Now I've got a DVB-S card and a DVB-T card together, VDR's channels management just isn't good enough, so because of all sorts of other niggles and because I don't like C++ enough to make big changes to VDR I want to press ahead again with boxstar's DVB support. Few comments/suggestions to boxstar: -roadmap: boxtar itself does not seem to show EPG unless it is incorporated into manage timers and recordings. Anyhow, I really hope you implement TVOnScreen type of EPG viewer and similar EPG search -plugin for automated timers. -OSD: not much is said about that but I hope it will scale according to the resolution and be full-coloured. -I assume that boxstar is developed to be full client-server solution which allows multiple fully independent clients. What would be nice addition because of the today's motherboards is that bostar-daemon could be run on multiple PCs for single system. This would allow to use cheap mATX boards that have one or two PCI slots to build a massive (?) system of e.g. 6 DVB cards. Some kind of master server might be needed for centralized recordings, timers etc. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Boxstar plans (was Re: Support for different frame rates?)
On Tue, 06 Jan 2009 20:47:14 +0200 Pasi Juppo p...@juppo.fi wrote: Few comments/suggestions to boxstar: -roadmap: boxtar itself does not seem to show EPG unless it is incorporated into manage timers and recordings. Anyhow, I really hope you implement TVOnScreen type of EPG viewer and similar EPG search Yes, I want to be able to present the EPG in at least two ways, both in boxstar's frontend and in a web frontend. One way is like many TVs and STBs and vdr-admin's Timeline with the channels vertically on the left and the programmes in horizontal strips, the other is a vertical list of programmes for a single channel like VDR's Schedule and vdr-admin's Channels view. I do want to provide EPG searching too although I've never got round to enabling that plugin in VDR. -plugin for automated timers. Do you mean automatically record programmes with the same title? That's a feature I'd like to have too, and features I'd like have a good chance of making it in :). I'm not really thinking in terms of plugins though, one of the things I dislike about VDR is having to find and compile plugins separately apart from a few core ones available in Debian. If and when it gets popular enough for people to want to add their own features I'll probably have to provide a mechanism to extend boxstar without the core code having to be altered to accommodate each extension, but it'll be easier in python than C++, and I'll encourage them to be hosted on the main boxstar site or at least have a CMS where people can add links etc. -OSD: not much is said about that but I hope it will scale according to the resolution and be full-coloured. Yes, once hvid is fully developed. In the meantime video playing will stay mainly based around mplayer so the OSD will be limited to things like showing the channel number when the user changes it. -I assume that boxstar is developed to be full client-server solution which allows multiple fully independent clients. Yes. What would be nice addition because of the today's motherboards is that bostar-daemon could be run on multiple PCs for single system. This would allow to use cheap mATX boards that have one or two PCI slots to build a massive (?) system of e.g. 6 DVB cards. Some kind of master server might be needed for centralized recordings, timers etc. I hadn't really thought about going that far. The basic principle isn't too difficult, but it makes configuration more difficult, especially as one of the problems I want to solve is being able to configure boxstar to know the relationships between channels such as BBC ONE on DVB-T being equivalent to BBC 1 South (in my case) on DVB-S so that if I want to set overlapping timers I can just choose BBC 1 and boxstar will automatically choose whichever card isn't already committed to another timer - like VDR can already do if both cards are the same type. Obviously it will be possible to assign priorities to cards. Managing these equivalencies and priorities across more than one PC could get very complicated. Hopefully Linux will support PCI-E cards with multiple tuners soon, and with PCI being phased out and assuming you can plug a PCI-E x1 card into a x16 slot while using onboard graphics, it should eventually be possible to have 4 such cards in one PC. But then you'd probably need an array of 10k rpm SAS HDs to keep up with recording from them all! -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
On Tuesday 06 January 2009, Ville Aakko wrote: On my Sony it is called Täyskuiva (in finnish), Heh, is this spelling error yours or Sony's? :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-femon-1.6.6/1.7.1
An updated Femon plugin is now available for both vdr-1.6.x and vdr-1.7.x branches. These versions should fix the reported leaking of frontend file handles. http://www.saunalahti.fi/~rahrenbe/vdr/femon/ BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
