Re: AW: [vdr] Doubling my available VDR disk space without cost or loss of convenience.
Carsten Koch wrote: martin wrote: ... go and get yourself a new hard disc :-) Well, that option is of course always available. ;-) Let's take a look at my vdr system: /video df -hT FilesystemTypeSize Used Avail Use% Mounted on /dev/hda2 xfs147G 12G 136G 8% / udev tmpfs253M 236K 252M 1% /dev /dev/hdb1 xfs149G 86G 64G 58% /vdr2 /dev/hdc1 xfs149G 115G 35G 77% /vdr3 /dev/hdd1 xfs149G 114G 36G 77% /vdr4 athlon:/ nfs148G 128G 21G 86% /athlon athlon:/mp3nfs233G 142G 92G 61% /athlon/mp3 athlon:/vdr5 nfs233G 107G 127G 46% /athlon/vdr5 athlon:/vdr6 nfs233G 141G 93G 61% /athlon/vdr6 athlon:/vdr7 nfs233G 179G 55G 77% /athlon/vdr7 athlon:/vdr8 nfs233G 170G 64G 73% /athlon/vdr8 athlon:/vdr9 nfs233G 210G 24G 90% /athlon/vdr9 athlon:/vdr10 nfs149G 75G 75G 50% /athlon/vdr10 athlon:/video nfs233G 211G 22G 91% /athlon/video It would still be nice to integrate videos from other sources seamlessly. And: 20 disks are twice as much trouble as 10 disks. My older disks have started to fail recently... That's nothing. ;-) I've currently have 36 HDDs with a total capacity of 8,3 TB. 7,4 TB used and 0,9TB free. A projection of about 1TB of missing things and another TB of recordings still on DVDs that i hadn't copied over. (Note to myself: Remember to by a HDD each month for the next 3 month, so that i can finally put the DVD priode behind me.) And above i haven't counted the about 1TB of misc space i have. And most of it i have actually watched, it took a few years to record all of that! Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] Doubling my available VDR disk space without cost or loss of convenience.
Norbert Goebel wrote: Matthias Schniedermeyer wrote: Not excatly. I would call it semy-online-storage. Normaly the HDDs are switched off. But as they are connected to USB-Power-Switches they can be switched on/off automatically by the computer.(*) Hi, I just got interested when I read USB-Power-Switches and the possibility to switch on/off the hdds automatically by the computer. As a quick google search only showed rubbish on the first 3 pages searching for usb power switches it would be nice if you could post some links to such products. The ones i use are from Gembird and are called SIS-pm. http://www.gmb.nl/main.asp?mode=itemN=2755 It comes with a simple Linux-Commandline-Tool (including Source) that i patched for my needs. AFAIR on Sourceforge or somewhere else there is another Commandline-Tool. Unfortunatly i can't tell you were to buy them, as i buy mine at my local hardware-wholesaler. Last time i looked they cost 19.90 EUR + VAT per piece. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: Switch box
Rainer Zocholl wrote: [EMAIL PROTECTED](Norbert Goebel) 13.09.06 18:21 Matthias Schniedermeyer wrote: Not excatly. I would call it semy-online-storage. Normaly the HDDs are switched off. But as they are connected to USB-Power-Switches they can be switched on/off automatically by the computer.(*) Hi, I just got interested when I read USB-Power-Switches and the possibility to switch on/off the hdds automatically by the computer. As a quick google search only showed rubbish on the first 3 pages searching for usb power switches it would be nice if you could post some links to such products. Those devices are relatively expensive. Typically 50E per Plug. Mine are much cheaper per Plug. 5 EUR + VAT actually. See other mail. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to detect if a timer was deleted?
Christian Wieninger wrote: Hi, for a new feature of epgsearch, I'd like to do a continuous check (in a separate thread) if any timer was deleted via OSD or SVDRP since the last check. The only thing I found so far is to build a timer array and compare it at each check with the current timer list. But if timers where modified meanwhile, the check can get quite complex. Any other idea? @Klaus: Is there a chance for a patch that extends cStatus with e.g. MsgDelTimer to get part of VDR, if I supply one ;-) Background: epgsearch currently creates a timer again if it was found by any search timer, even if the user previously deleted it. If I could detect which timer was deleted, I could put it in a done list to prevent the new creation. I know, I could create the done list already when creating the timer for the first time, but this causes other problems. Besides that: only timers that have been deleted are of interest, so why save all others too? Does epgsearch save any status from epg-data and/or timers? This point (don't recreate deleted timers, unless wanted) was an design criterion for Master-Timer from the beginning, so what i did in Master-Timer is(*): a) Mark the epg-data events that are already processed. b) Save the timers-list So in normal operation the marks from a) already prevent any unnecessary processing and when the configuration was changed only intersection of new timers are programmed(, or deleted or modified). As i don't know for what user-type epgsearch is, i can't say if you should go to the length of creating a proper state to operate on, or if more or less stateless is good enough. *: oversimplified! Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to detect if a timer was deleted?
Christian Wieninger wrote: Hi, Matthias Schniedermeyer wrote: Does epgsearch save any status from epg-data and/or timers? yes, but the 'done' approach is currently different: epgsearch marks and saves a broadcast as done only if it has been successfully and That wasn't what i meant. Second try with a but more elaborate description (still simplified) After Master-Timer is done with operation it saves the processed epg.data(/LSTE) as program.dat, including markers that a particular broadcast doesn't need to be processed again, unless it was modified (doesn't happen very often on the channels i record). The next time Master-Timer runs it compares the current epg.data with the saved program.dat and only uses the intersection of changed or new broadcasts(and checks for deletions too) to match with the torecord-config-file and the resulting matches are put into the timers.dat. The timers in timers.dat are marked as already programmed, new or changed. (Actually that's only internal as the different parts of Master-Timer are consecutively evaled from a wrapper script, and only the end-result of everything already programmed hits the HDD. (If there was no VDR instance MIA, which is only relevant for installations with 2 or more VDRs (like mine with 3 VDRs), otherwise Master-Timer would exit when the connection to VDR failed)) So Master-Timer always knows what was, what is and what should be. And in default configuration and in normal operation that means that a deleted timers isn't even see as MIA because Master-Timer doesn't process the epg-broadcast a second time and when it want's to propagate a change to a timer, because of changes in the epg-data and/or torecord-config-file, it checks if the timer still exists and only applies the change when i still exists. Unless the config-option for checking for MIA timers is set, then all missing timers are reprogrammed. completely recorded. So any recording break because of timer conflicts or a crash will be noticed and epgsearch will automatically search for a repeat of the broadcast (provided that proper settings for the search timer exist). The drawback of this approach is that deleting a timer will lead to the described situation, because it it not yet 'done' in terms of epgsearch. Currently one has to disable the timer to prevent the recording and I would like to solve this in the next release. This could be easily done if VDR could notify plugins about timer deletions. I solved this particular problem the other way arround, program everything and when someting gets done(*) delete the timers not needed anymore. (As Master-Timer isn't tied into VDR, which means that unless it's a cronjob there is no way of knowing when it will run the next time, that's the only way to be on the safe side.) As i record many things this way i also know when i can delete the first run-timer of something to fallback to a rerun when at the time of the first run there is something in the way. *: For me that means that i successfully cut the recording. I use my own cutting-solution, in the script that executes the final cutting the summary of the recording is put into the done-file of Master-Timer. The next time Master-Timer runs all timers matching a done-entry are deleted. (ATM i have 13040 things in my done-file. :-) ) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr on PS3
Darren Wilkinson wrote: Matthias Schniedermeyer wrote: Video is inherently bandwith intensive. At least (for PAL): 720x576x4x25 = about 40MB/s (*) 1920x1080x4x25 = about 200MB/s And that's taking aside ANY of the other processing. Decoding, IDCT, YUV-RGB transformation and so on. Also taking aside the total bandwith killer, when you have to scale the material. AFAICT the vector cores COULD(*2) help you with the first parts, but the rest has to be done by the 3(,?)Ghz RISC PPC-CPU and shoveling that much data back and forth may be a bit much, without any acceleration. But on the other side the PS3 systems is supposed to have an impressing memory-bandwith, which could rescue the day. So unless someone tries there is no way to be sure, but for the time beeing i'm sceptical. IOW: - SDTV maybe - HDTV no way without acceleration *: x4 isn't a typo. Most systems use 32 bit per color. 24 bit packed format isn't used anymore AFAIK. *2: If you have software that can use the SPUs, but unless someone writes a Decoder-Library with SPU support you can only use the Main-CPU. Bis denn Most people AFAICT use vdr for sdtv and while HDTV may or may not be out of the question due to bandwidth sdtv definitely isn't. In fact I have linux on my xbox which has much less bandwidth than even the ps2 and most distros for that have a dvd player. The thing with the XBOX is that it pretty much has a standard PC with a standard Geforce 3.5 (AFAIR it is something between the 3 and the 4). So it should have hardware acceleration, which makes it a quite good platform for a video player, although i wouldn't buy one myself. I am actually looking into a building a working dtv rig for the (original) xbox but am much more limited by the mere 60mb (64mb-4mb for the framebuffer) of memory and others have made mythtv clients for it. As someone else pointed out though a PS3 for linux doesn't make much sense unless you already want a PS3. Any applications it runs will, due to the 88mb ram, probably *feel* slower than a 1-2ghz pc with 128mb+ of ram running an quivalent distro even without graphics accelleration. If i'm not mistaken you mixed it with the memory that the Wii has. The PS3 and the XBox360 have 512MB total. And i'm quite sure that one of them was a split-memory-architecture (256MB/256MB) and the other one has a unified-memory-architecture. So the PS3 should have something around 240MB or 500MB of available memory. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr on PS3
Pasi Juppo wrote: Matthias Schniedermeyer wrote: Clemens Kirchgatterer wrote: Matthias Schniedermeyer [EMAIL PROTECTED] wrote: I'd say the only downside of the Linux support kills it as a VDR platform. Graphic is NOT accelerated. That's the only downside i'm aware of, and i can understand Sony a little in this point. Otherwise all game developers could just skip paying licensing royalties and just develop for [EMAIL PROTECTED] but why should this matter for multimedia (video) applications? ok, we (most likely) don't have hardware accelerated xvmc, but 6 vector cores to do it in software. Video is inherently bandwith intensive. At least (for PAL): 720x576x4x25 = about 40MB/s (*) 1920x1080x4x25 = about 200MB/s And that's taking aside ANY of the other processing. Decoding, IDCT, YUV-RGB transformation and so on. Also taking aside the total bandwith killer, when you have to scale the material. AFAICT the vector cores COULD(*2) help you with the first parts, but the rest has to be done by the 3(,?)Ghz RISC PPC-CPU and shoveling that much data back and forth may be a bit much, without any acceleration. But on the other side the PS3 systems is supposed to have an impressing memory-bandwith, which could rescue the day. So unless someone tries there is no way to be sure, but for the time beeing i'm sceptical. IOW: - SDTV maybe - HDTV no way without acceleration *: x4 isn't a typo. Most systems use 32 bit per color. 24 bit packed format isn't used anymore AFAIK. *2: If you have software that can use the SPUs, but unless someone writes a Decoder-Library with SPU support you can only use the Main-CPU. I hardly believe that PS3 would suffer at all when doing HDTV without acceleration. There was a test several months ago of the cell processor. It handled 48 SDTV MPEG2 streams in real time and displayed, thus scaled down, them all at the same time on HDTV screen. I don't think hardware acceleration is needed for x264 HDTV decoding. Only problem is the DRM part and of course BR disc playing under Linux. I just tried playing back a Mpeg4 AVC HDTV (1900x1080) video(*) with xine -V xshm That sould be pretty much unaccelerated. My system (CORE 2 Duo E6700, or about the fastest not extreme CPU you can currently buy, sided by 2GB DDR2-800 RAM and a Geforce 7600GT) does that with about 90% CPU for the xine task and 9% for X. IOW it pretty much sucks up all power from one of the two cores. So i revise my guess. The PS3 may still be able to play back a Full HDTV stream. Maybe even a decoder just using Altivec optimizion provides enough raw horsepower to do the job. (IIRC the PowerPC-CPU of the PS3 has Altivec.) If not, offloading just enough of the processing to the SPUs to have enough horsepowers left for the rest may be the way to go for a PS3-Media-Center. *: http://www.apple.com/quicktime/guide/hd I used the http://www.apple.com/quicktime/guide/hd/bbcmotiongalleryreel.html Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Heikki Manninen wrote: On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. Conax 4.00e is able to decrypt 2-3 channels at the same time. Although when used with VDR 1.5.0 it is not. Also when using previous versions of If the CAM doesn't respond to a QUERY, then how is VDR supposed to know whether it can decrypt more than one channel at a time? I think i can say with resonable confidence that most VDR-Systems don't change at a regular basis, but stay unchanged (more or less) for sometimes years(*). So why not make a probe capabilities function (where you could also probe unsafe things, with a bit of user interaction(*2)) and then store the information away in a config-file. The next time the system has significant changes you can probe again. *: My first VDR-machine is for e.g. practically unchanged (hardware-wise) since i build it sometime near end of 2000(!). *2: Ever installed Windows? I've seen: The screen may go blank and the computer can freeze, or something in the same sense. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.0: PrimaryLimit ?
Stefan Huelswitt wrote: Hi, I'm playing around with 1.5.0 Initialy I wasn't able to tune to any channel. Even for FTA vdr kept saying not available. It took me nearly an hour to find the reason for that: I had set PrimaryLimit=20 I have this setting since ages, but cannot say why anymore. I found that vdr runs with PrimaryLimit=0 only. So my question is: what is the meaning of PrimaryLimit if there is exactly one setting which makes vdr operable? FYI: I think the change is in cDevice::SetChannel(), line 674. In the GetDevice() call the priority was Setup.PrimaryLimit, now is 0. The (at least original) meaning is to prevent a recording with the Primary Device, in a multi card setup, with a too low priority. At least when i proposed that option many years ago a recording on the primary Device effectively prevented live-viewing, even in a multi-card setup. So with this option it could be made sure that a low priority recording would be recorded with a secondary card, or not at all. AFAICT that isn't a problem anymore, because of Transfer Mode. But i personally only have multiple single-card systems so i can't check it. (And i haven't looked anything live for years) So my guess would be that this option can be erased. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR gets stuck in a reload-loop
Hi I have recently updated from VDR 1.2.6 to 1.4.6 I have the problem that once VDR emergency exists, for whatever reason, it never gets the recording started again in time, so it emergency exists again and again until the recording has ended. If i manually disable the timer, wait a few seconds and reenable timer the recording works. Added note: It is an encrypted channel and the CAM-found-message always appears a few seconds after VDR started, but before VDR tunes the channel and starts the timer. A few seconds later a: 'ERROR: no useful data seen within 10498860 byte of video stream' message appears and VDR emergency exists. According to UPDATE-1.4.0 VDR supposedly has to wait for the CAM to be initialized before it starts a recording, but it doesn't appear to do so for me. I have my own start-script, which does about the same as the runvdr example. (It reloads the driver before VDR is started again) Until a few minutes ago it didn't start VDR with the watchdog-parameter, which i added after looking into the runvdr-example. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR gets stuck in a reload-loop
Matthias Schniedermeyer wrote: Hi Added note: It is an encrypted channel and the CAM-found-message always appears a few seconds after VDR started, but before VDR tunes the channel and starts the timer. A few seconds later a: Ups. This must read: AFTER VDR tunes the channel and starts the timer. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On 01.07.2007 19:40, Georg Acher wrote: On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote: or better or whatever. cool, no problem. what? you signed a NDA that does not allow you distribute the os in the first place? your bad. Once again, and now in capitals. IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE WITH IT AS YOU LIKE. You won't find any HDMI chip without NDA for the forseeable future. No NDA, no chips, no HDMI. So there's simply no choice at all and analog inputs are slowly dying. A card without HDMI is already dead in the market. If only the hardware vendors where as united as the movie-industry. The result would have been a clear F*ck You. But with all that backstabing from the left/right/up/down/center, the only looser is the group between their chairs. (The consumer). It's the same with the current PNR and SWIFT data-transfers to the USA. If the EU would be united and say F*ck You the USA could happily close their borders. But i'd say the backlash from the economy would open up the borders faster than you can say 'Bad Idea'. According to Wikipedia (sorry german) http://de.wikipedia.org/wiki/Liste_der_L%C3%A4nder_nach_Bruttoinlandsprodukt the EU (in total) has a greater gross domestic product than the USA! And the EU has more citizens (about 300M USA, about 492M EU). But in all those cases the unity lacks and the Power Player wins. I'd say: Murphy's law proven right again. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On 01.07.2007 21:10, Georg Acher wrote: On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote: If only the hardware vendors where as united as the movie-industry. HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and HDMI. As long as they can sell chips and licenses, they don't care about the consumer, looks quite united to me ;-) That's the back-stabbing-part i meant. You can be certain that there is someone to pick up a knife laying around. Here is another example of such a knife thing from today: http://hardware.slashdot.org/hardware/07/07/01/0221213.shtml They invented it because they think that someone will want it (and most probably someone will), just the same as Intel/Silicon Image. Another word would be: anticipatory obedience (vorauseilender Gehorsam (translated by dict.leo.org)) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to identify timers
Bernd Juraschek wrote: Hello list, I want to do some kind of offline modifying vdr timers, but I don't know how to identify timers. If I use the timer id to change or delete VDR timers, then this will go wrong if VDR has deleted some timers since the remote site has retrieved the timer list. Using timer properties is not a solution because the user can change timers also locally using OSD. The simple answer: You can't. For my Master-Timer i insert the event_id into the last field of the timer. So Master-Timer finds a timer to be modified by going through the list of timers and looking for it's marker. Is there another way to distinguish timers (or channels, recordings, ...)? I think it would be useful to assign some UUID to VDR objects. This ID must not be changed while modifying the object. Channels are uniquely identified by the 'channel ID': see vdr.5 -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On 18.11.2007 17:01, Klaus Schmidinger wrote: Maybe it actually is about time for me to build a new VDR. I'll probably take a look at the Reel Extension HD PCI. But that means I'll also need a new motherboard with at least five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD). On my desktop PC I'm using a passively cooled Pentium M with 1.86GHz, which works really good, so maybe that's also a viable choice for a new VDR. I guess it goes without saying that modern motherboards have a gigabit Ethernet port and graphics on board. Does anybody have a recommendation for such a board? There exist PCIe - PCI converters, the one my local dealer offers converts one PCIe to 4xPCI. (Price-point is about 150 EUR IIRC) AFAIK there are no specific limitations to which PCI-card can be used in that thing. So it shouldn't be a problem to get enough PCI-Slots even with recent mainboard that mainly have 3/3 PCIe/PCI and last but not last 1 PEG. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Pseudo-real-time h264 transcoding of mpeg2 vdr recordings
On 15.01.2008 09:35, Magnus Hörlin wrote: I'm sorry for bothering you with a question that should possibly have been sent to the mplayer mailing list. Next week I'm going to Tenerife to relax by the pool, but I don't want to miss any biathlon, alpine- or cross-country skiing transmissions, because then I can't relax Therefore I have made a script that scans my video dir for new recordings and starts encoding them to h264/AAC right away to a bitrate of around 800kbps, which is what I can send from my server. Since I will have internet access in my hotel room, I'm hoping to sit on the balcony with my laptop and play the recordings using mplayer or xine while downloading them. One problem is that my vdr server is too slow to do it in real time and my vdr client is too fast (AMD BE-2400), so when mencoder catches up with real-time it exits instead of continuing until the vdr file is closed. And the same goes for wget which I planned to use for downloading the files. I guess there are many very simple ways to do this so I hope you don't mind my wasting your time by asking here. The obvious way would be to let vdr start encoding when the recording ends, but I don't want to wait for that. There must be a better way. For the download-part the easiest(tm) way is to rate-limit the connection. wget --limit-rate scp -l rsync --bwlimit With a little head-start on the encoding and a matching limit a continous download shouldn't be a problem. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
On 03.02.2008 11:17, Klaus Schmidinger wrote: So, here's the straw poll: Should there be a stable version 1.6.0 now, based on what's in version 1.5.14, but without DVB-S2 or even H.264 support? Is the CAM Handling regarding multiple parallel recodings (on the same channel) fixed? I had to revert to 1.2 after the 1.4 was such a disaster in that regard. If yes then: yes. If no then: I don't care. Can't use it anyway. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
On 03.02.2008 12:17, Klaus Schmidinger wrote: On 02/03/08 12:06, Matthias Schniedermeyer wrote: On 03.02.2008 11:17, Klaus Schmidinger wrote: So, here's the straw poll: Should there be a stable version 1.6.0 now, based on what's in version 1.5.14, but without DVB-S2 or even H.264 support? Is the CAM Handling regarding multiple parallel recodings (on the same channel) fixed? Have you tried version 1.5 yet? No And as the 1.2-version works great i have no real pressure for anything newer. (*) The only exception is channel-scanning, but for that i have a 1.4-version in a parallel-setup, that i can run for a bit of time when there are no recordings pending. I will try a 1.6-version after a little time has passed, but it heavily depends on me having to update the Linux-install to a recent state or not. It can do multiple parallel recordings with the same CAM (if the CAM supports this). That's not a case i'm very much interested in, at least as long as i don't know it is actually usable in my case. But even then, Murphy will prevent it from being useful 90% of the time it could have been useful. So it's still nothing i would count on. *: Taking aside that i can't update my DVB-computers linux-installation to anything recent as the 1.2-version of VDR can't cope with a recent glibc (threading). But that's not a real problem as i don't use my DVB-computers for anything else. :-) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2GB file sizes and cutting recordings
On 16.03.2008 17:55, Florian Gleixner wrote: Hi, i use dvbcut to cut my recordings. After cutting i can rename the resulting mpg file to 001.vdr, delete the index file and run genindex and then i have a perfect cutted recording. This works well for all recordings that are smaller than 2GB. If the file is 2GB, i tried to concat the 001.vdr 002.vdr ... files and use dvbcut to make a new 001.vdr. Unfortunately vdr does not like files 2GB. But i also canot use split -b 2097152000 to make new vdr files, because it would not split at GOP. Or is that not needed? It would be easier if vdr could handle files 2GB - and tools like genindex too. Handling these files for playback would be enough for me. Or is there another preferred method cutting files? I dont want to use vdrs cutter because my remote does not really work well and i read that i can only cut every iframe. dvbcuts sliders are really easy to handle :-) The core problem is index.vdr The field for offset into the ???.vdr-file is 32bit i.e. 4GB max. Don't remember if it is used signed (which reduces it to effectivly 2GB) or for 'good measure', but that's the reason for the 2GB limit per file. This has been discusses several times in the past and Klaus doesn't want to (backward incompatible) change the format of index.vdr. So for short: Larger than 2GB is a no go. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2GB file sizes and cutting recordings
On 16.03.2008 22:20, Florian Gleixner wrote: Matthias Schniedermeyer wrote: On 16.03.2008 17:55, Florian Gleixner wrote: Hi, i use dvbcut to cut my recordings. After cutting i can rename the resulting mpg file to 001.vdr, delete the index file and run genindex and then i have a perfect cutted recording. This works well for all recordings that are smaller than 2GB. If the file is 2GB, i tried to concat the 001.vdr 002.vdr ... files and use dvbcut to make a new 001.vdr. Unfortunately vdr does not like files 2GB. But i also canot use split -b 2097152000 to make new vdr files, because it would not split at GOP. Or is that not needed? It would be easier if vdr could handle files 2GB - and tools like genindex too. Handling these files for playback would be enough for me. Or is there another preferred method cutting files? I dont want to use vdrs cutter because my remote does not really work well and i read that i can only cut every iframe. dvbcuts sliders are really easy to handle :-) The core problem is index.vdr The field for offset into the ???.vdr-file is 32bit i.e. 4GB max. Don't remember if it is used signed (which reduces it to effectivly 2GB) or for 'good measure', but that's the reason for the 2GB limit per file. This has been discusses several times in the past and Klaus doesn't want to (backward incompatible) change the format of index.vdr. So for short: Larger than 2GB is a no go. Thanks, its now clearer to me. So the question is: if i use split -b ... to split the files, i surely don't split at a iframe. Is this a problem? I also found out, that i probably can use genindex -r after using dvbcut to generate vdr compatible files. It seems to split at a iframe. 2GB are small files nowaday. vdr should be probably able to replay bigger files even if there is no index file? But that has Klaus to decide i think. For me personally playbackability with VDR was never a priority. I've been using VDR for recording since Oktober 2000, back then i had to write my own cutting scripts, since VDR didn't had the cutting function until later. A few month later i began writing my Master-Timer. VDR has been the recording slave ever since. ;-) Since 2003 i use vdrsync/tcmplex for the actual cutting (As it demultiplexes and remultiplexes the recording, i.e. it verifies that the recording is good(tm)) to single .mpg-files which i than watch archive. Mostly i playback at my computer, especially since i bought a 1920x1200 24 TFT a few month back, but for TV playback i also have a Pinnacle Showcenter 200. I only use VDR playback to cut music-videos (or to find the beginning of a song i want to cut out, to be more precise), that's the only playback related feature where VDR excels anything else i have tried. Over the years i've recorded more than 13.000 broadcasts, stored on 55 HDDs with a total capacity of 20 TB. ;-) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2GB file sizes and cutting recordings
On 16.03.2008 22:55, Florian Gleixner wrote: Matthias Schniedermeyer wrote: For me personally playbackability with VDR was never a priority. I've been using VDR for recording since Oktober 2000, back then i had to write my own cutting scripts, since VDR didn't had the cutting function until later. A few month later i began writing my Master-Timer. VDR has been the recording slave ever since. ;-) Since 2003 i use vdrsync/tcmplex for the actual cutting (As it demultiplexes and remultiplexes the recording, i.e. it verifies that the recording is good(tm)) to single .mpg-files which i than watch archive. Mostly i playback at my computer, especially since i bought a 1920x1200 24 TFT a few month back, but for TV playback i also have a Pinnacle Showcenter 200. I only use VDR playback to cut music-videos (or to find the beginning of a song i want to cut out, to be more precise), that's the only playback related feature where VDR excels anything else i have tried. Over the years i've recorded more than 13.000 broadcasts, stored on 55 HDDs with a total capacity of 20 TB. ;-) For me playbackability with VDR is really needed. I like dvbcut more than vdrsync because with the linear/logarithmic sliders you can really easy find start and end of ads or similar. For find the cutting-marks i wrote my own browser based solution back in 2000 (with little improvements here and there over the years). With it, it only takes seconds to find the begin end of the recordings. No ads in my case. :-) As long as dvbcut displays the frame-numbers, you could use something else for the actual cutting. My browser base solution is basically only for finding the frame-number offsets into the index.vdr. Then there is my next script that uses the begin/end offsets and pipes everything between those offsets into vdrsync for further processing. IOW finding the cutting marks and the actual cutting doesn't necessarily have to be done by the same program. For me this work-splitting is perfect as a known perfect(tm) recording is paramount for me. It can take months until i actual watch a recording, so i have to know immediatly if a recording is broken or not, so i can rerecord it (if possible). I've never had a recording thas was damaged, after vdrsync was successfully done with it. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which extension for TS files?
On 04.01.2009 11:55, Klaus Schmidinger wrote: Up to now VDR has used names like 001.vdr for its recording files. While moving to Transport Stream as the recording format, I need to use a different file name extension, and so was wondering which one to use. My first idea was *.ts, for Transport Stream, but when I point, for instance, Konqueror to such a file, it thinks it is a Qt Translation Source. So I was wondering if I should use *.mpg instead. This one is identified by Konqueror as an MPEG file and will make it launch a proper player. What do you think about this? Is *.mpg also appropriate for h.264 encoded files? AFAICT the norm is to name the suffix after the container-format used, not what is stored inside the container. (Or would you use different suffixes for different types of files you put into a .tar-Archive?) So as .ts is the container it should be the appropriate suffix. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which extension for TS files?
On 04.01.2009 22:34, Klaus Schmidinger wrote: On 04.01.2009 19:21, Nicolas Huillard wrote: Klaus Schmidinger a écrit : Up to now VDR has used names like 001.vdr for its recording files. While moving to Transport Stream as the recording format, I need to use a different file name extension, and so was wondering which one to use. My first idea was *.ts, for Transport Stream, but when I point, for instance, Konqueror to such a file, it thinks it is a Qt Translation Source. So I was wondering if I should use *.mpg instead. This one is identified by Konqueror as an MPEG file and will make it launch a proper player. I think the option is clearly defined now. I little thing that always annoyed me was that every recoding file had the .vdr extension, whatever the actual contents (it seemed like the file name was used as an extension). See: index.vdr info.vdr marks.vdr resume.vdr Maybe you will find an opportunity to improve this at the same time... Well, how about leaving the .vdr part away altogether? I'd suggest .dat for binary and .txt for text content. More or less another container question. :-) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 27.12.2012 13:21, VDR User wrote: On Thu, Dec 27, 2012 at 10:20 AM, fnu v...@auktion.hostingkunde.de wrote: ... there are way too much changes at the moment :) FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ... Keep in mind, all these changes are occurring in the _developer_ version of VDR, not stable. If package maintainers choose to use developer rather than stable versions, they should expect things like this. Maybe the problem isn't the changes, it's that they've picked the wrong version to work with. Just a thought. When software advances at glacial speeds(*) reality tends compensate for that over time. See the permanent Beta-marking that many Google-Services tended to have in the past. *: The timestamp of the 1.6.0 release (a.k.a. vdr-current.tar.bz2) on ftp.tvdr.de is: 23.03.2008, -- Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 27.12.2012 16:55, VDR User wrote: Matthias Schniedermeyer: Pointing out that the last stable release of VDR having an old timestamp has nothing to do with people _choosing_ to use the developer version, which is warned and well-known to possibly contain changes that will cause problems for those expecting stable behavior. The advice has always been, and will always be, if you expect stable then use stable. It is, or can be, a dependency problem. If your main use-case is for e.g. provided by a plugin that only works with the lastest development-release you are more or less forced to use a development release. Or some other example i use a self compiled VDR, but i'm also a Debian user. Debian is currently in a freeze-phase for the next stable release. So i looked which version of VDR i could install: apt-cache show vdr | grep Version Version: 1.7.28-1 There isn't even a 1.6 version to install only a single 1.7 Version. (Technically i'm on unstable, but there shouldn't be that much difference as long as Wheezy isn't released ) And this is Debian, famous for being ultraconservative when it is about stability. I'm smelling a problem of reality. When the caravan moves on Linus realized that when he changed the development-model of the kernel last time some years ago: Yearlong gaps are a problem in reality. -- Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] small patch for vdr.c: continue even with read-only video directory
On 10.03.2013 20:40, Peter Münster wrote: On Sun, Mar 10 2013, fnu wrote: But to change it in a global way like this is IMHO not a way to go. Did you understand my suggestion? Here again: not writable: warning, not readable: exit. Is that a problem for real-life systems? For most people read-only is a plain error? Read-only CAN for e.g. happen after an error when the filesystem is mounted with error=read-only (ignoring the runtime-case, when VDR is already running when that happens). And you may not see a warning and only notice that something went wrong after you lost a recording that didn't happen. A not starting VDR is a little more noticable than an apparrently working one that just can't record anything. So if VDR suddenly changes behaviour i can gurantee you that at least 1 person will be bitten by it. As you said you are a single person, would you think it is fair to the person that will losse a recording to have lost it because you wanted a change in behaviour that was only for yourself with no apparent gain for others? -- Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SVDRP - Bug or feature
On 13.03.2013 11:44, Michael Frank wrote: Hello, I'm not sure whether this is a bug or an intended feature: When using an SVDRP command the result displayed always lacks the hyphen in the last line, e.g. lstc returns 250-2609 Canvas (MPEG4);TV Vlaanderen:12722:HC56M2S0:S19.2E:22000:502+8190=27:76=dut@3:43:1817,1818,1819,100,500:12802:53:1119:0 250 2610 DAYSTAR TV;TSA:11067:VC56M2S0:S19.2E:22000:2026=2:3026=@3:0:0:31307:1:1040:0 221 HD-vdr closing connection The example was taken from vdr-1.7.27 from the yavdr distribution 0.5 This is also true for lstr, lste etc. This marks the last entry, or in other words - is the continuation marker. -- Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
