Re: [vdr] Serious bug? VDR v1.4.4 deletes recordings
Yes, VDR remove recordings, depending on its priority and lifetime value. See MANUAL: a recording will last at least the number of days specified in "LIFETIME" before it is deleted because another recording with a higher priority needs the diskspace. Set LIFETIME to 99 and it will stay until you delete it manually. Helge. Pasi Juppo schrieb: > Hi, > > For some reason VDR has decided to remove recordings. I've been > suspecting this for some time but now I'm sure. I've been recording Tomi > Traktori (a serie for kids) and there used to way more recordings that > single page. Now only single page and all recordings in 2007 have been > deleted. > > There is no indication in log files that VDR had removed these > recordings (although I'm not 100% whether there was log entry because > logs data back only to 13th of May). > > What could be the reason for this and how to prevent this? There have > been over 40h of free space on the disk so that is not the reason. > > Br, Pasi > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
Frank Schmirler schrieb: > On Tue, 4 Nov 2008 15:31:21 +0100, jori.hamalainen wrote > >> PCH itself supports multiple audio (and subtitle) tracks at least on >> other formats - but I believe that with VDR it might not be working. >> I need to test this more when I get back to my PCH. >> >> http://www.hdd-player.de/syabas/showthread.php?tid=1777&page=1 >> >> I don't know if this URL recommendation is because of the initial >> tests made by some guys where they received video but not audio. I >> think this +1 as a default might become a problem with channels with >> multiple sound tracks. Maybe there could be additional feature that >> do not automatically add +1 if count.apid > 1? >> > > As of PES, without a "+audio_pid_index" all audio and dolby pids will be > streamed. So on a channel with only one audio pid, a "+1" won't make any > difference. For channels with multiple audio/dolby pids, the streamdev html > page already contains specific links for each. Look for the -tags with > class apid and dpid respectively. Rather add the vod/prebuf/tvid attributes > there. > > With ES it's obvious that you get either video or audio, never both at the > same time. By default (without +index) you get the video pid. If there is none > (radio channel) you get the first audio pid. > > According to an open bug report, PS actually sends PES. > > Finally TS normally doesn't consider the actual audio pid. It streams most > relevant pids (not only audio and video) according to the PMT. This format > should be the best choice. It may not have worked by the time the guy at the > NMT forum tried the first time, as streamdev didn't have a PAT repacker by > that time. It is part of streamdev 0.3.4. Have you tried TS? > > The TS from the streamdev is not recognized by the PCH (neither SD nor HD). I tried to remux SD through vlc and this works quite well. I assume that the PCH only supports a certain "flavour" of TS packets because if you remux HD material with a TS-Remuxer for the PCH (see http://www.hdd-player.de/syabas/showthread.php?tid=2285 or http://www.hdd-player.de/syabas/showthread.php?tid=3353 ) it works. Maybe it would be a solution to patch the streamdev plugin in a way that it generates a TS valid for the PCH. - Added suffix for URL (TS w/ "C-123-123-123.ts or S-12-123-123.ts", ".ps", ".vdr" for PES and ".mpeg" for ES, extern no suffix) >>> I wonder why these are needed? >>> >> I think PCH uses filename based analyzing for stream type >> recognition. It was at the web forum above that URL like >> "/PES/*.vdr" should work. >> > > I doubt that *.vdr is known as an official filename extension for PES files. > Maybe any (possibly otherwise unknown) extension would do? Could you verify > that? > > PCH supports VDR recordings since firmware 080221. The VDR PES format is not really "detected" but the *.vdr extension is used to recognize it. >> So I guess if you see it possible to add this into tree - please do >> it. But if you see adding filename suffix a bad decision then don't. >> For my own experiments I can do this patching manually. And the >> patch is already out there for interested people to find. >> > > Filename suffixes have already been suggested a while ago. I'd be fine with > them if they are necessary. > > >> Now the problem is that h.264 streaming is not working. It should >> happen via TS-container? And for this probably streamdev should be >> modified. I cannot tell why it is not working as PCH does not give >> any clue on it. Just returns to menu. >> > > It is a problem of the TS itself, if you remux it with TS-Doctor or TS4Np it works quite well (see above). Helge. > Haven't checked if the PES remuxer actually supports h.264. TS would be a > better choice anyway. > > Good luck, > Frank > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
Frank Schmirler schrieb: > On Tue, 11 Nov 2008 13:02:48 +0100, jori.hamalainen wrote > --- PMT 0 --- Packet : 1 >>> The fixed file starts with a PMT packet. Could PCH be choking on the fact >>> that the TS stream starts right in the middle of nowhere? >>> >> I think this is a good quess. I don't know how much PCH reads the >> stream for PMT table (first 10kB, first 100kB,...?), so if it does >> not have it in time it quits the stream. >> >> So could streamdev be easily modified to provide PMT at stream >> start? And could PMT be rewritten later if new streams are found. >> With this I mean on first PMT you have audio/video-stream. And >> subtitle appears 60 seconds from the start so give new PMT with >> private subtitles streams as well? >> > > I opened a bug report (http://www.vdr-developer.org/mantisbt/view.php?id=496) > and posted a quick hack which should strip off all packets before the first > PAT and probably some packets before the first PMT (hopefully not including > the PMT). The PMT part needs to be elaborated. Sending a PMT with basic > information first should be possible and sounds like a good idea. I'll take a > look into this the next days. > > >> How about the other symptom I was giving output. My VDR machine and its >> mplayer. Sometimes it recognizes stream as MPEG-2, and sometimes >> H.264. What do you believe, problem with TS stream or problem with >> Mplayer stream recognition. >> > > Could have the same cause... > > Frank > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > After your patch TSDoctor does not find a PAT at all! Tested with both versions of the patch. Somebody in the NMT forum claims that he has it working with vdr-1.7.1 without any modifications. H264 streams should work too according to this post: http://www.networkedmediatank.com/showthread.php?tid=1696&pid=92157 Hope this helps. Helge. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput - front ends not detected?
Simon Baxter schrieb: > Hi > > I'm trying to install xineliboutput on a EPIA SP13000, but am getting the > following error: > > [r...@freddy xineliboutput-1.0.3]# make install > Makefile:68: > Makefile:69: xine-lib not detected ! frontends will not be compiled. > Makefile:70: > Makefile:170: libextractor not found. > make: Nothing to be done for `install'. > > > [r...@freddy xineliboutput-1.0.3]# rpm -qa | grep xine > xine-0.99.5-5.fc10.i386 > xine-lib-1.1.15-3.fc10.i386 > xine-lib-pulseaudio-1.1.15-3.fc10.i386 > totem-xine-2.24.3-1.fc10.i386 > > > > What am I missing? > > libextractor?!?!?! And probably the xine development libraries too... Regards, Helge. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] ARM based devices for VDR server and client
As far as I know uses the reel NetClient an ARM core but I am not shure which one and if there is an additional graphics processor onboard. As long as nobody buys this box and opens it, we won't know. Helge. Paul Menzel schrieb: Dear list, I searched the Web but could not find a lot of reviews or tests about ARM based VDR systems. The goal is to have a VDR device which consumes the „least possible“ amount of power. I heard that ARM based devices are good for this. Does anyone on this list have any experiences using ARM based devices? 1. Since the boards are mostly small one needs to use mostly USB devices, doesn’t one? 2. Is the performance high enough to playback SDTV? It should. 3. What about HDTV? 4. Especially the Beagle Board [1][2] was covered a lot in the press. But it is not completely free, i. e. the specifications and the toolchain is not freely available, is not it [3]? Sorry, if I am wrong about this. If there is any information I missed on the Web, please point me to it. Thanks a lot, Paul [1] http://en.wikipedia.org/wiki/BeagleBoard [2] http://beagleboard.org/ [3] http://en.wikipedia.org/wiki/Texas_Instruments_TMS320 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 10 Year Anniversary of VDR
Congratulations! You and everybody who contributes does a great job. Don't bother about deadlines, there is a life beyond watching TV! Thank you for having such a stable system. Helge. Klaus Schmidinger schrieb: It has been exactly 10 years since version 0.01 of VDR (originally named "OSM" - On Screen Menu) was released. I want to use the occasion to thank everybody who has contributed to VDR, but also those who simply use VDR in their every day life. I for one couldn't imagine watching tv without VDR any more. Special thanks go to the people running the VDR-Portal (www.vdr-portal.de). Originally I intended to release version 2.0 of VDR at the 10th anniversary, but as ever so often, I ran out of time. But I'm still on it - stability comes before deadlines ;-) I hope you don't think I'm blowing my own horn here, I just didn't want the date to pass by without a remark... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
