Hi,
I've built RPM packages for 1.3.26. Video directory and epg file location is the same as in the 1.2.6 packages, config files are in /etc/vdr13 instead of /etc/vdr. So you can safely install 1.3 in parallel to the 1.2.6 packages. vdr contains minimal patches. the su patch, the patch to use a broadcast variable instead of sleep in cDvbPlayer and pagedown.diff from Udo Richter. I also removed the check for NPTL and vdr does run with NPTL if available. Post success stories here, this check has to go before 1.4 :-)
The packages are at
ftp://ftp.suse.com/pub/suse/i386/supplementary/misc resp. ftp://ftp.suse.com/pub/suse/x86_64/supplementary/misc
and it's mirrors.
cu Ludwig
I've built RPM packages for 1.3.26. Post success stories here, this check has to go before 1.4 :-)
Hi,
you asked just at the right moment. I`m about to renew my vdr running for 5 years now, currently still a variant of 1.2.6 (no suse package), and just tried linvdr to have a look at some plugins. But since I want to have this computer do some more jobs I installed a fresh Suse 9.3 and then your new rpm. The configuration used: Fujitsu Siemens Scenic X100 (cheap, silent); celeron 2.8GHz, 256MB; 1* Hauppauge DVBs 1.3 FF card, 1* Hauppage Nova
Result: the rpm installed without problems, vdr works, but uses only one dvb card. This seems to be no problem of the 1.3 rpm but of Suse 9.3 though?! In yast both cards can be configured and both are shown in hardware info, but for nova the driver is marked inactive! I couldn`t find out how to change this yet.
(LinVdr 0.7 installed in 5 minutes and used both cards without problems)
Greetings
Michael
M. Fiegert wrote:
[...] In yast both cards can be configured and both are shown in hardware info, but for nova the driver is marked inactive! I couldn`t find out how to change this yet.
The dvb support in YaST is probably only useful for basic setups with one card. Take a look at /usr/share/doc/packages/dvb/README.SuSE and create hwcfg-static files manually or put the modules in DVB_LOAD_MODULES (/etc/sysconfig/dvb). This way you can also ensure a load order so your Nova won't suddenly become the primary card.
cu Ludwig
Ludwig Nussel schrieb:
[...] In yast both cards can be configured and both are shown in hardware info, but for nova the driver is marked inactive! I couldn`t find out how to change this yet.
The dvb support in YaST is probably only useful for basic setups with one card. Take a look at /usr/share/doc/packages/dvb/README.SuSE and create hwcfg-static files manually or put the modules in DVB_LOAD_MODULES (/etc/sysconfig/dvb). This way you can also ensure a load order so your Nova won't suddenly become the primary card.
Thanks, I will try this in the evening.
Unfortunatly also the rpm seems not to be that perferct yet. This morning I had a black TV screen. I got back vdr only after kill -9 vdr13. I will look into this more detailed also today evening. I did not see anything interesting in /var/log messages yet (exceppt that its flooded with PID change messages)
Greetings
Michael
Ludwig Nussel wrote:
Hi,
I've built RPM packages for 1.3.26. Video directory and epg file location is the same as in the 1.2.6 packages, config files are in /etc/vdr13 instead of /etc/vdr. So you can safely install 1.3 in parallel to the 1.2.6 packages. vdr contains minimal patches. the su patch, the patch to use a broadcast variable instead of sleep in cDvbPlayer and pagedown.diff from Udo Richter. I also removed the check for NPTL and vdr does run with NPTL if available.
I absolutely cannot use VDR without the SourceCaps patch, since I have 3 DVB-S cards connected to 2 different dishes.
I also kind of like my own "delete_resume" patch which dramatically reduces the number of redundant resume.vdr files. See my posting from March 3rd, 2005. Of course, that patch is just "nice to have", not "cannot live without it".
I guess there will be many people who require one or another patch before they can use vdr.
Any ideas?
Carsten.
M. Fiegert wrote:
Ludwig Nussel schrieb:
[...] In yast both cards can be configured and both are shown in hardware info, but for nova the driver is marked inactive! I couldn`t find out how to change this yet.
The dvb support in YaST is probably only useful for basic setups with one card. Take a look at /usr/share/doc/packages/dvb/README.SuSE and create hwcfg-static files manually or put the modules in DVB_LOAD_MODULES (/etc/sysconfig/dvb). This way you can also ensure a load order so your Nova won't suddenly become the primary card.
Thanks, I will try this in the evening.
Unfortunatly also the rpm seems not to be that perferct yet.
A perfect package is only possible with a perfect vdr and vdr 1.3 is still considered a development version :-)
This morning I had a black TV screen. I got back vdr only after kill -9 vdr13. I will look into this more detailed also today evening. I did not see
Does your vdr run 24/7?
anything interesting in /var/log messages yet (exceppt that its flooded with PID change messages)
That's normal as the default channels.conf is just copied from vdr 1.2.6.
cu Ludwig
Carsten Koch wrote:
Ludwig Nussel wrote:
I've built RPM packages for 1.3.26. Video directory and epg file location is the same as in the 1.2.6 packages, config files are in /etc/vdr13 instead of /etc/vdr. So you can safely install 1.3 in parallel to the 1.2.6 packages. vdr contains minimal patches. the su patch, the patch to use a broadcast variable instead of sleep in cDvbPlayer and pagedown.diff from Udo Richter. I also removed the check for NPTL and vdr does run with NPTL if available.
I absolutely cannot use VDR without the SourceCaps patch, since I have 3 DVB-S cards connected to 2 different dishes.
I've never heard about that one or forgot about it because I don't need it. Was it ever posted here for official inclusion?
I also kind of like my own "delete_resume" patch which dramatically reduces the number of redundant resume.vdr files. See my posting from March 3rd, 2005. Of course, that patch is just "nice to have", not "cannot live without it".
I guess there will be many people who require one or another patch before they can use vdr.
Any ideas?
Try to convince Klaus to include the patches. I'd like to keep vdr 1.3 patches in the package to a minimum at the moment so Klaus can be blamed for bugs rather than the patches ;-)
cu Ludwig
Ludwig Nussel wrote:
Carsten Koch wrote:
Ludwig Nussel wrote:
I've built RPM packages for 1.3.26. Video directory and epg file location is the same as in the 1.2.6 packages, config files are in /etc/vdr13 instead of /etc/vdr. So you can safely install 1.3 in parallel to the 1.2.6 packages. vdr contains minimal patches. the su patch, the patch to use a broadcast variable instead of sleep in cDvbPlayer and pagedown.diff from Udo Richter. I also removed the check for NPTL and vdr does run with NPTL if available.
I absolutely cannot use VDR without the SourceCaps patch, since I have 3 DVB-S cards connected to 2 different dishes.
I've never heard about that one or forgot about it because I don't need it. Was it ever posted here for official inclusion?
Yes. It startet on January 18th, 2004 with a posting by Christian Schuld (the patch author). I posted a version on April 6th, 2005, that was adopted to the latest VDR, see attachment.
I also kind of like my own "delete_resume" patch which dramatically reduces the number of redundant resume.vdr files. See my posting from March 3rd, 2005. Of course, that patch is just "nice to have", not "cannot live without it".
It started on January 30th, 2005. I posted it again on March 21st. See second attachment.
I guess there will be many people who require one or another patch before they can use vdr.
Any ideas?
Try to convince Klaus to include the patches. I'd like to keep vdr 1.3 patches in the package to a minimum at the moment so Klaus can be blamed for bugs rather than the patches ;-)
OK.
Klaus, as I said above, on a system without diseqc and with more than one dish, I believe Christian's SourceCaps patch is a must. It's also not very complicated and thus should not impose a high risk of breaking something in vdr.
My patch is just a performance optimization. On a system with very many recordings, it can become quite significant, though. It is even smaller than the SourceCaps patch, though and thus should not impose any risk of breaking something in vdr.
So, can you please, please, please include these two in the next VDR version? :-)
Carsten.
Carsten Koch wrote:
Ludwig Nussel wrote:
Carsten Koch wrote:
Ludwig Nussel wrote:
I've built RPM packages for 1.3.26. Video directory and epg file location is the same as in the 1.2.6 packages, config files are in /etc/vdr13 instead of /etc/vdr. So you can safely install 1.3 in parallel to the 1.2.6 packages. vdr contains minimal patches. the su patch, the patch to use a broadcast variable instead of sleep in cDvbPlayer and pagedown.diff from Udo Richter. I also removed the check for NPTL and vdr does run with NPTL if available.
I absolutely cannot use VDR without the SourceCaps patch, since I have 3 DVB-S cards connected to 2 different dishes.
I've never heard about that one or forgot about it because I don't need it. Was it ever posted here for official inclusion?
Yes. It startet on January 18th, 2004 with a posting by Christian Schuld (the patch author). I posted a version on April 6th, 2005, that was adopted to the latest VDR, see attachment.
I also kind of like my own "delete_resume" patch which dramatically reduces the number of redundant resume.vdr files. See my posting from March 3rd, 2005. Of course, that patch is just "nice to have", not "cannot live without it".
It started on January 30th, 2005. I posted it again on March 21st. See second attachment.
I guess there will be many people who require one or another patch before they can use vdr.
Any ideas?
Try to convince Klaus to include the patches. I'd like to keep vdr 1.3 patches in the package to a minimum at the moment so Klaus can be blamed for bugs rather than the patches ;-)
OK.
Klaus, as I said above, on a system without diseqc and with more than one dish, I believe Christian's SourceCaps patch is a must. It's also not very complicated and thus should not impose a high risk of breaking something in vdr.
Well, I still believe that the majority of systems will have only one LNB, anyway, and any reasonable multi-LNB system should use a multiswitch.
Anyway, am I missing something here, or will this patch _require_ SourceCaps to be set? If I look at
bool cDvbDevice::ProvidesSource(int Source) const { int type = Source & cSource::st_Mask; + if(type == cSource::stSat && frontendType == FE_QPSK) + { + for(int i = 0;i<MAXSOURCECAPS; i++) + if(sourceCaps[i] == Source) + return true; + return false; + } + else return type == cSource::stNone || type == cSource::stCable && frontendType == FE_QAM - || type == cSource::stSat && frontendType == FE_QPSK || type == cSource::stTerr && frontendType == FE_OFDM; return true; }
it would appear to me that this won't work if no SourceCaps are set. If you really want this to go into VDR then you need to make sure a system that does not have SourceCaps set (which IMHO will be the majority) will still work.
BTW: what's with this:
diff -ru /hetis/home/cko/VDR/sources.c VDR/sources.c --- /hetis/home/cko/VDR/sources.c 2004-12-26 12:58:52.000000000 +0100 +++ VDR/sources.c 2005-04-05 22:12:55.421326944 +0200 @@ -68,7 +68,7 @@ int pos = 0; bool dot = false; bool neg = false; - while (*++s) { + while (*++s && !isblank(*s)) { switch (toupper(*s)) { case '0' ... '9': pos *= 10; pos += *s - '0';
Obviously this has nothing to do with SourceCaps - but what's it for then?
My patch is just a performance optimization. On a system with very many recordings, it can become quite significant, though. It is even smaller than the SourceCaps patch, though and thus should not impose any risk of breaking something in vdr.
This is probably not worth the effort, because in a future VDR version I will most likely store the selected audio track in that file, too, and then deleting it wouldn't make sense any more.
Klaus
Klaus Schmidinger wrote: ...
it would appear to me that this won't work if no SourceCaps are set. If you really want this to go into VDR then you need to make sure a system that does not have SourceCaps set (which IMHO will be the majority) will still work.
I fully agree that the default must be "source is provided".
I suppose a global flag "SourceCapsSet" which is initialized to false and which is set true true by ParseSourceCaps should do the trick?
After all, this is Christian's patch, so I do not want to take it over unless Christian wants me to. Christian, are you reading this? Would you like to fix your patch so Klaus can accept it?
BTW: what's with this:
diff -ru /hetis/home/cko/VDR/sources.c VDR/sources.c --- /hetis/home/cko/VDR/sources.c 2004-12-26 12:58:52.000000000 +0100 +++ VDR/sources.c 2005-04-05 22:12:55.421326944 +0200 @@ -68,7 +68,7 @@ int pos = 0; bool dot = false; bool neg = false;
while (*++s) {
while (*++s && !isblank(*s)) { switch (toupper(*s)) { case '0' ... '9': pos *= 10; pos += *s - '0';Obviously this has nothing to do with SourceCaps - but what's it for then?
I do not know. My guess is that Christian needed this in a previous version of cSetup::ParseSourceCaps? After all, cSetup::ParseSourceCaps is calling cSource::FromString. I believe this hunk can safely be omitted.
Carsten.
Klaus Schmidinger wrote: ...
My patch is just a performance optimization. On a system with very many recordings, it can become quite significant, though. It is even smaller than the SourceCaps patch, though and thus should not impose any risk of breaking something in vdr.
This is probably not worth the effort, because in a future VDR version I will most likely store the selected audio track in that file, too, and then deleting it wouldn't make sense any more.
Please consider the performance hit that VDR takes when it has to open an extra 500+ files (I currently have 519 recordings) just to bring up the recordings menu. It really does take a long time here already!
Your philosophy has always been to store all information displayed in the recordings menu in the directory entry. I believe you have done that for a good reason: do make the creation of the recordings menu's contents perform well. Why break that philosophy now?
Automatically removing "resume.vdr" files that point to the first few seconds of a recording would again allow you to stick to that philosophy 100%, since you would not have to read the file at all to display the recordings menu.
Carsten.
Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger) 19.06.05 12:12
Well, I still believe that the majority of systems will have only one LNB,
The adavntage why i still use (the meanwhile relativley expensive) VDR is it's ability to use up to four cards, mixed(!) DVB-T, DVB-C, DVB-T. No commerical can do that (and will never, i assume). But they usualy have a clean "resource management" which i am missing at VDR.
anyway, and any reasonable multi-LNB system should use a multiswitch.
AFAIK there approx. 100 downloads of the LNBsharing patch for 1.3.x. As it is of very limited (actually no, as VDR already "locks" the LNB in a single card system) use for the SingleLNB guys i assume there are at least 50 users in that unlucky situation, to have only one wire, which can ONLY be solved with VDR, AFAIK.
Affordable "Single-Wire-Solutions" are no solution - they will block many transponders.
There is a list of the most dangerous things in the world, two i rember: "A softworker with a solder iron" and: "A software with a hardware patch".
The second fits your suggestion to fix missing the resource managent with a mulit-switch ;-).
And: On Motor dishes a mulit-switch will not help much.
Too recently some asked if VDR is so clever that in a two card system DVB-S and DVB-T will chosse the transmission on the other system if the program is avaible on both...
I assume that should be solved from the ground and not by separate "patches". Else it will be an endless story.
Ooops, i forgot to mention the "CA"-resources...
Rainer
Hi Carsten, Hi Klaus,
I will prepare a patch that doesn't change VDR's default behaviour. You are absolutly right about that.
On Sunday 19 June 2005 13:49, Carsten Koch wrote:
Klaus Schmidinger wrote: ...
it would appear to me that this won't work if no SourceCaps are set. If you really want this to go into VDR then you need to make sure a system that does not have SourceCaps set (which IMHO will be the majority) will still work.
I fully agree that the default must be "source is provided".
I suppose a global flag "SourceCapsSet" which is initialized to false and which is set true true by ParseSourceCaps should do the trick?
I will try a per device flag approach, which will give a bit more flexibility.
After all, this is Christian's patch, so I do not want to take it over unless Christian wants me to. Christian, are you reading this? Would you like to fix your patch so Klaus can accept it?
Yes, I will try, I will post to the list so that you can review it, when it is ready.
BTW: what's with this:
diff -ru /hetis/home/cko/VDR/sources.c VDR/sources.c --- /hetis/home/cko/VDR/sources.c 2004-12-26 12:58:52.000000000 +0100 +++ VDR/sources.c 2005-04-05 22:12:55.421326944 +0200 @@ -68,7 +68,7 @@ int pos = 0; bool dot = false; bool neg = false;
while (*++s) {
while (*++s && !isblank(*s)) { switch (toupper(*s)) { case '0' ... '9': pos *= 10; pos += *s - '0';Obviously this has nothing to do with SourceCaps - but what's it for then?
I do not know. My guess is that Christian needed this in a previous version of cSetup::ParseSourceCaps? After all, cSetup::ParseSourceCaps is calling cSource::FromString. I believe this hunk can safely be omitted.
No, tried this, but omitting breaks the patch. The reason for this small patch is that without the !isblank(*s) term the cSourceFrom::FromString won't accept a list of source ssepareted by white spaces, which is need to keep the parsing simple. For expample parsing a string like "SourceCaps = 1 S13.0E S19.2E S5.0E" will lead to three cSource::FormString(...) calls with this input strings "S13.0E S19.2E S5.0E" "S19.E S5.0E" "S5.0E" Without the !isblank(*s) term the return value would be stNone, which is not exactly what i need ;-) But if you dislike this behaviour, i will change the Parse function and leave cSource untouched?
Have a nice day (and nice holiydays)
Carsten.
Christian
Ok, here the current status: every works fine.
The dvb support in YaST is probably only useful for basic setups with one card. Take a look at /usr/share/doc/packages/dvb/README.SuSE and create hwcfg-static files manually or put the modules in DVB_LOAD_MODULES (/etc/sysconfig/dvb). This way you can also ensure a load order so your Nova won't suddenly become the primary card.
Ok, this was easy and works good (two hwcft-static files). Thanks!
This morning I had a black TV screen. I got back vdr only after kill -9 vdr13. I will look into this more detailed also today evening. I
did not see
Does your vdr run 24/7?
yes it does. The partly frozen vdr (it still gave messages about events in the log, but the UI was frozen, the screen black) appeard at least twice a day. When I switched to one channel, I got the same problem, UI froze at once (channel info stayed there for 25min). So I disabled all automatic channel info collection, stripped down the channel info to what I really watch. Now vdr is running for 2 days without problem.
Michael
Klaus Schmidinger wrote:
...
it would appear to me that this won't work if no SourceCaps are set. If you really want this to go into VDR then you need to make sure a system that does not have SourceCaps set (which IMHO will be the majority) will still work.
Klaus, I have made the changes that you requested and also changed the patch to your python-like indentation style. See the attached version.
Do you like it this way? Is there anything else you want me to change or can it go into vdr 1.3.31 as it is now?
Carsten.
Carsten Koch wrote:
Klaus Schmidinger wrote:
...
it would appear to me that this won't work if no SourceCaps are set. If you really want this to go into VDR then you need to make sure a system that does not have SourceCaps set (which IMHO will be the majority) will still work.
Klaus, I have made the changes that you requested and also changed the patch to your python-like indentation style. See the attached version.
Do you like it this way? Is there anything else you want me to change or can it go into vdr 1.3.31 as it is now?
I won't be changing anything in that area before version 1.4. After that I'll need to see how a general solution can be made, which also takes into account that different devices might need different DiSEqC commands.
Klaus
-
Carsten Koch -
Christian Schuld -
Klaus Schmidinger -
Ludwig Nussel -
M. Fiegert -
Rainer Zocholl