Re: [vdr] [Fwd: Re: let vdr ignore non vdr directories ?]
On 20.04.2009 10:56, Peter Dittmann wrote: A simple use case: * standalone settop box with VDR and DVD recording capability * OS gets a seperate small partition * /videoX get the big rest To add some more variations to the same solution the others already mentioned: - Mount your big disk to /mnt/data - Put video to /mnt/data/video - either: - pass /mnt/data/video directly to VDR - put a symlink from /video to /mnt/data/video - bind-mount /mnt/data/video to /video All theee solutions work without any trouble, and there's plenty of other space on /mnt/data available. @Klaus: Since many people seem to miss this obvious solution, maybe you should add this as example to the documentation? Not only that. Most people start from some kind of distribution. However it seems to have developed into a kind of standard to mount the video partitions directly. E.g. ctvdr/debian uses (I think ...) /var/vdr/videoX directly to mount the partition. Strange as it finally uses symlinks to create the /videoX. So change would be very small indeed. Althought the suggestions seems sensible and simple non of the distributions have currently been thinking about this issue ... Seems like this hasn't been that obvious, so thanks for suggesting it ;-) Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Fwd: Re: let vdr ignore non vdr directories ?]
Quoting Peter Dittmann peter.dittm...@pldsnet.com: E.g. ctvdr/debian uses (I think ...) /var/vdr/videoX directly to mount the partition. The directories are named /var/lib/video.XX and this are not necessary partitions, but could be of course. Strange as it finally uses symlinks to create the /videoX. So change would be very small indeed. I can't see any evidence for this symlinks, and I don't know a reason for this. The vdr gets told via the option '-v /var/lib/video.00' where the video dir is located. But you see what I'm pointing to. The distries are usually mounting the partition directly and then use the xxx/video[.]xx directly. Using the previous suggestion would mean the path tree of most of the distributions need to be somewhat different. E.g. like this: /var/lib/vdr |- video.00 | |- video | |- somthing-else | |- video.01 |- video |- somthing-else-2 ... So better suggestion for the distri maintainers would be to use the \mnt tree for mounting any partitions. Then always create a (dummy) directory on the video partitions (video or vdr). Then linking this mounted directories as /var/liv/video.xx. /mnt/video.00 -- /mnt/[h|s]d[a-z][0-9] /mnt/video.01 -- /mnt/[h|s]d[a-z][0-9] ... /var/lib |- video.00 -- /mnt/video.00/video | |- video.01 -- /mnt/video.01/video ... Quite a difference to what is now. Hopefulls the distri maintainers read this and make some sensible changes to the standard path tree to make VDR's video directories collision free with temp directories for burn ... Obviously the distries are not based on usual use configurations currently for how to handle the huge temp files for some of the tools for burning. This make life more complex and will cause a lot of individual effort to modify the installation after the distribution is installed. You can individually do a lot. It's just a matter of knowledge and ideas. But as I assume that currently 80..90% of VDR users are starting from a distri rather than LFS this is a field issue. And obviously the safe mounting suggestion for a single disc system wasn't that obvious. So there is room for improvement ;-) Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Antwort: Re: OT: VDR for grandparents
[EMAIL PROTECTED] schrieb am 26.10.2008 16:57:51: has anyone on this list any experience in setting up VDR for older people like grandparents? It would be nice, if she/he could share her/his experience or point me to information on the WWW. I have experience with second best thing after grandparents. A totally clueless user. Since I have setup VDR as the backend sitting near the dish, and added a MediaMVP box next to the TV set, she can use it, record stuff, delete recording, everything. We are using the Hauppauge MediaMVP together with the vdr-plugin-vompserver on the VDR system. Another vote for MediaMVP and vompserver. The user interface is IMO easier to operate than commercial PVRs such as the Humax, and the noisy recorder can be kept out of the living room. While I have not had experience with this myself, I do know a few users who've set up VDR for (grand)parents and wives. From the feedback I've heard, VDR works really well in those scenarios which I think says a lot! ;) I can second that. I set up a box for my brothers family almost 3 years ago and it still running with the ancient 1.3.24. The box is actually offline, 250km away and only needed some checks every few months at first. Now it's like a VW beatle: it runs, and runs, and runs ... He actually dont't care about the system setup, he doesn't even have the root password either ;-)) There seems to be some keys to success. 1.Chosing a stable(unfancy) plattform. I used an seemingly ancient PIII OEM(Siemens) plattform. These OEM systems are usually rock stable, quite quiet and relativly low power. With the stable TT-FF premium card there is also a stable plattform. Make sure that your system design is good (cooling, I/O attachment). Invest some time in the optical design (doesn't need to be fancy eigher) for WAF. Low WAF creates problems even while everything runs nicely ;-) 2.Limit yourself Only add the minimum set of plugins for doing the daily routines. Keep things as simple as possible. Sort the GUI to have the daily routines on the initial menu. Move special features into submenus to not bother the user with it. Use a stable distribution that is flexible enought for the task. I started with c't vdr distribution (Debian !) but hand tuned a lot of the distribution components for easy use and to fix some issues after some testing. Don't bother about latest versions. Once the system runs nicely only change what is broken or adding a needed feature. 3.testing, testing, testing Problem is not VDR and it's functions. Problem is to make the components working together in everydays tasks. You should use the system for the NOB-user by yourself for some time before delivery. Test the features and test it again after some weeks/months time. Crux is mostly the scripts and system setup beside VDR. Think about automated clean-up of log files and similar stuff. I had quite some fun with MySQL thrashing the HD and forgetting to delete the garbage. Some scripting beside VDR is also a pain, like vdrconvert and burn creating directories. In a single HD configuration the temp directories for those may end up in the video directory tree. But VDR don't like empty directories. So make shure scripts creating them also leaves a dummy file in it. Otherwise VDR cleans up the directory that burn/vdrconvert need for temporary data causing spurious fails of those plugins. regards Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Antwort: Re: [patch] channels with same pids+channels update
[EMAIL PROTECTED] schrieb am 10.04.2008 14:53:04: ua0lnj schrieb: Hi If it's interecting for anybody. .. And other feature, this is deleting absent channels. If provider was deleted channels, you need delete it from channels.conf manually. After this patch, vdr auto deleting channels, which not present on transponder in sdt. Need select delete absent channels in dvb settings menu, but if you selected channels update or transponder update. I am very interested in this feature. My providers (astra/hotbird) are smart enough not to send not to much garbage, but deleting of unused channels is really a pain. I am at 4500 Channels in my channels.conf and I am pretty sure that at least 30 % of them are long gone. Is it possible to have that feature seperated ? @kls ... and include it in the mainline ? Best regards Peter How about something simpler and implement a manual delete on request, like a negativ channel scan ? My usual way of cleaning up channels.conf is structuring it using the : feature in the conf file. The last managed entry is :5000 so I have 4999 channels that I can sort and structure as I like. Channels =5000 are automaticly added from VDR, hence I only need to occationally delete entries 5000 and I'm fine. New channels I need will be moved manually into my managed range and stay there until I want to get rid of them. I would actually prefer something manual instead of being triggered by the provider and their potential lazyness and their **ironie on** notorious standard adherence **ironie off**. regards Peter___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Christian Wieninger wrote: perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that? This would be a dirty ugly hack. There must be some pseudo-recording running so VDR does not restart the recording over and over again. And then we'll end up with a recording hack that looks like a timer but does not block devices and does not write to disk and has no recording folder and and and... The alternative would be to implement a generic task scheduler and make timers one special type of schedule. This would get REALLY big. Yes, but it will be the much better design. It will open the option to do VDR related timed and maintainance tasks. Don't reply this should be external scripts, as there is no way external scripts know what state VDR currently has without a lot more complexity. These are EPG scans (internal, infosatepg, nextview), sleeptimers, switchonly timers, cleanup tasks of plugins and so on. Think about external EPGs, especilly the ones that need VDR to tune to a channel, like infosatepg or nextview. This is painfull hack doing his outside VDR as these tasks mutually collide with VDRs internal activities and need to be integrated for realy using a KISS principle. The only benefit of scripting is that more people tend to write and change scripts that writing plugin or extend VDR code. The second is also cause by Klaus's reluctance to take over patches. Where there are patches there is need to change some VDR behaviour, so this behaviour should be changed. Of couse Klaus should be one deciding the way to implement it but he should be more open here to stimulate more people to contribute to VDR. It's like Linux and Linus, the first is a scaling system the second not. Same for VDR and Klaus ;-) The idea to create now a external Shutdown class by a second person seems like a good starter. It should be done for other functionalities too. kind regards Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVD plugin - sound jerky??
[EMAIL PROTECTED] schrieb am 19.10.2006 23:28:52: PPPClear(4)! Play I don't think these messages are dvd-plugin related, as I cannot find them via grep (vdr-xine ?). With which dvds did you get these messages? I've mostly noticed this will the Red Dwarf series DVDs, but it seems to happen on most. It doesn't happen if I play the DVD directly in xine. Clear(5)! SetAudioChannelDevice: 0 I've had this problem for ages and never found any resolution to it as it's really only a problem with DVDs that have a lot of chapters. How is a lot of chapters defined (10, 50, 100, ..) ? I think this might only be happening at chapter marks - which is every 5-10 minutes on some DVDs May be you can analyse the structure of the DVD using IfoEdit ? Chapters are a misconception. DVD consist of Domains, TitleSets, Titles, PGCs, PGs and Cells (top to bottom structure). Chapters are in fact only pointer markings optionally attached to PGs. The transitions between structural blocks get larger with higher structural level. E.G on PGC level it's almost like starting a new presentation, e.g. audio and video needs to be completely restarted. May be this were the VDR dvd-plugin has it's problems to play some structural transitions seemless. May be you can post a copy of the .IFO files on the questionable disc and I can give you some hints or advices (I work with DVD software profecionally and have access to all the specs and tools neccessary). kind regards Peter___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Cheapest FF card?
On Wed, Oct 18, 2006 at 05:43:43PM +0200, Peter Dittmann wrote: Partial nonsense ;-)) CF has nothing to do with CI and smartcards. You need a CI adapter an an CAM adapter card for the smartcard. I find no comparison/info on CI and CF on wikipedia. Could you give me some info please? How does the CAM interface with the PC? A DVB card (may) have a special connector for a CI interfase. This is a card or 3 1/2 bay adapter to insert a CAM card into. The CAM does the actual decryption or authorisation of the provider. The smartcard is inserted into the CAM to provide the actuall keys/subscritions for the decryption The CAM always interfaces with the DVB card directly as the decryption/authorisation is done in hardware. For safety the authorisation data are never transfered on an open bus like USB/PCI. Alternatively there are standalone smartcard readers (USB/serial). No, I clearly see it is illegal. But these are not working without some legally doubtfull patches/plugins of VDR. Beside the skipping of CI and CAM (which is patent violaton but not realy illegal) these can use illegal software keys, which is illegal in most of the world. Therefore nobody here on the list will give you any added detailes. NP, I am not going that route either. The official method is bying a CI adapter and CAM card for your DVB card. Even this is a violation of some provider rules as it's not certified by them. Never mind if it is a violation but I have no money to buy an FF card. Get it? There are FF and budget DVB cards available with CI interface adapter (e.g. Technotrend / Hauppauge). You need one of both WITH CI adapter as a minimum. The CI costs around 50€ for the Technotrend/Hauppauge cards and the CAM is another 50..100€ This is costwise in between a plain (cheap) budget and a FF DVB card. So for me to view pay channels with a budget card, what do I do? Can I get a generic USB CI card? So that I place a CAM which houses a smart card to decrypt channels? No chance here. CICAM always interface directly with the DVB card (FF or budget), no external (USB) solution is available. So it's eigther a DVB+CI+CAM+Smartcard or smardcard reader (USB or serial) + software CAM [illegal !!!] It's sad that there is no 'gray' softcam option that only does the CAM opearations in software but needs the smartcard always. This would be legaly a 'gray' area as it only violates patent regulations of the decryption owner but would not circumvent the decryption. The 'banned' plugin/patch combines this 'gray' CAM simulation with a fully illegal 'simulation' of the smardcard ;-)). It's in this respect like the 'banned' CSS library which also contains 'illegal' CSS keys for DVD or just plainly breaks the encryption. I belive for DVB there could be a legally acceptable version of a software CAM when it does CAM simmulation only. If the keys are always from the smartcard there would be no 'illegal' decryption. For DVD this would only being possible if the CSS key of a 'legal' CSS library would be legally licenced from the DVD forum. Unfortunely this will (likely) never happen. For DVB the keys are transferable on the smartcard and the smard card keys are legally optained by the user when he subscribes at a program provider. So using a software CAM which uses keys from a smartcard via a card reader only violates patents of the decryption owner + program provider regulations (which CI+CAM also violates already !), but it would not being considered 'illegal' in europe. The 'illegal' softcam can be stripped down to do just that (makes the use ethically acceptable for me as a user), but the whole tool goes beyound that. Unfortunely there may be some legal court fight neccessary to settle this legally as the patent owners and providers may put up a fight first agains whomever distributes the 'gray' CAM simulation. So this option is also very likely not going to happen. kind regards Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Cheapest FF card?
[EMAIL PROTECTED] schrieb am 18.10.2006 17:22:14: On Wed, Oct 18, 2006 at 02:06:07PM +0300, Suur Karu wrote: Luca Olivetti wrote: Also I wish to view pay channels with it. That's not (officially) possible with a budget card. Why not? Techotrend have CI interface for own budget card. My idea is to interface it externally. I have bought a CF card reader. PMI but what has CF got to do with CI? Thanks. Am I barking up the wrong tree by any chance? My idea is to interface things using the PCI and USB bus. I plug in a USB CF card reader, decrypt the data from CAM and talk to the budget card using the PCI bus. Does it make sense or nonsense? Partial nonsense ;-)) CF has nothing to do with CI and smartcards. You need a CI adapter an an CAM adapter card for the smartcard. Alternatively there are standalone smartcard readers (USB/serial). But these are not working without some legally doubtfull patches/plugins of VDR. Beside the skipping of CI and CAM (which is patent violaton but not realy illegal) these can use illegal software keys, which is illegal in most of the world. Therefore nobody here on the list will give you any added detailes. The official method is bying a CI adapter and CAM card for your DVB card. Even this is a violation of some provider rules as it's not certified by them. regards Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
