Op Wo, 4 februari, 2009 10:16, schreef Morfsta:
Hi,
Goodmorning!
Due to an attempt on OS upgrade and thus kernel upgrade I'm grudgingly (it worked for me for months with no issues so why would I want to change it for now?) trying to make the transition from multiproto to S2API. I have two DVB-T cards and a NOVA-S2-HD (HVR4000 lite). I have downloaded a vanilla vdr-1.7.0 applied the h264 patch and the s2api patch and install S2API from Steven Toth's mercurial repository.
You might want to try Igor's repo http://mercurial.intuxication.org/hg/s2-liplianin) since Steve's hasn't been updated for over 3 months. This however won't fix your problem perse.
On booting the kernel loads all the modules and I see the various frontends and when I start VDR it loads all of the relevant firmware okay. When I start VDR it won't show any of the FTA channels on DVB-T or DVB-S (not even tried S2!) and all I get is "Channel Not Available". I wish VDR were more descriptive in why the channels are not available! :-)
Did you install mine S2API patch from 7-10 for VDR 1.7.0? Because this is the latest version and this has been tested with DVB-T, DVB-S, DVB-S2 and DVB-C. And with succes! ;)
BTW, you might want to increase the logging for VDR or check the logfiles in /var/log what VDR has thrown out (Ubuntu uses /var/log/user.log for instance). My best guess is an frontend timeout error. This means that a timeout (duh!) occured when tuning to the selected channel. This can mean a reception problem (not likely, but good to point out) or a problem in your channels.conf.
Apologies if this has been asked before, but is there anything I'm missing? Is the problem that I took my channels.conf from my multiproto VDR and something has now changed in the format?
The Multiproto channels.conf should be interchangeable with S2API. But *some* modulation types didn't exist in S2API when I wrote the patches and you need to check this for yourself. You need to check the settings (Red button to edit in the TV Channels overview) and see if they are indeed correct and change them accordinly. My best guess, is that the modulation types are wrong.
It would be good to get this working as my old OS is now messy and really needs a clean build with a shiny new kernel and I can't patch up to date multiproto with the old HVR4000 patches (a few FAILS which I guess I could fix, but might take some time as they don't look that trivial) and an older version of multiproto from HG doesn't compile on the new kernel!
Best to say, multiproto is not needed to get it al working. I've got the same kind of config as you ( NOVA-HD-S2 and a Gigabyte USB stick for DVB-T) and it works very good with S2API.
Can anyone point me in the right direction on what might be going on?
See the above ;)
Thanks
Regards,
Niels Wagenaar
On Wed, Feb 4, 2009 at 9:39 AM, Niels Wagenaar n.wagenaar@xs4all.nl wrote:
Goodmorning!
Morning Niels, thanks for getting back to me so quickly!
You might want to try Igor's repo http://mercurial.intuxication.org/hg/s2-liplianin) since Steve's hasn't been updated for over 3 months. This however won't fix your problem perse.
OK, done that.
Did you install mine S2API patch from 7-10 for VDR 1.7.0? Because this is the latest version and this has been tested with DVB-T, DVB-S, DVB-S2 and DVB-C. And with succes! ;)
Specifically I have installed:
vdr-1.7.0-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff vdr-1.7.0-s2api-07102008-h264-clean.patch
the only other plugin I am using at this stage is the reelbox plugin output which seems to work fine.
BTW, you might want to increase the logging for VDR or check the logfiles in /var/log what VDR has thrown out (Ubuntu uses /var/log/user.log for instance). My best guess is an frontend timeout error. This means that a timeout (duh!) occured when tuning to the selected channel. This can mean a reception problem (not likely, but good to point out) or a problem in your channels.conf.
Now I have recompiled it all and when I run VDR I get: -
vdr: error while reading '/video/config6/channels.conf'
in /var/log/user.log I see: -
Feb 4 10:06:01 morfsta vdr: [17791] loading /video/config6/channels.conf Feb 4 10:06:01 morfsta vdr: [17791] ERROR: unknown parameter key 'A' Feb 4 10:06:01 morfsta vdr: [17791] ERROR: error in /video/config6/channels.conf, line 2
Line 2 is a DVB-T channel: -
BBC ONE;BBC:730000000:A0B8C34D34G32I0M16P0T2Y0:T:27500:600:601=eng,602=eng:0:0:4 165:9018:4101:0
This channel works fine in vdr-1.7.0 with multiproto and there are definitely no reception problems as all DVB-T and DVB-S channels works fine with previous implementation (which I have kept in a seperate parition obviously!).
The Multiproto channels.conf should be interchangeable with S2API. But *some* modulation types didn't exist in S2API when I wrote the patches and you need to check this for yourself. You need to check the settings (Red button to edit in the TV Channels overview) and see if they are indeed correct and change them accordinly. My best guess, is that the modulation types are wrong.
It seems that the channels.conf isn't interchangeable as the multiproto channels.conf now seems to be rejected and I can't even start VDR now. Perhaps the leading A is now unsupported in the options, is there a way I could possibly modify the file to remove this stuff?
See the above ;)
Any more ideas? ;-)
The Multiproto channels.conf should be interchangeable with S2API. But *some* modulation types didn't exist in S2API when I wrote the patches and you need to check this for yourself. You need to check the settings (Red button to edit in the TV Channels overview) and see if they are indeed correct and change them accordinly. My best guess, is that the modulation types are wrong.
Sorry to double post but as an update I removed all DVB-T channels and then rescanned them using scan-s2 from http://mercurial.intuxication.org/hg/scan-s2/. It found all the channels on my transmitter. Also DVB-S channels seem to be working fine, not tried S2 yet.
The new format for DVB-T presented is: -
BBC ONE;BBC:730000:I999B8C34D34M16T2G32Y0:T:27500:600:601=eng,602=eng:0:0:4165:9018:4101:0
which is now accepted by VDR. However, I get a black screen when tuning to them. In user.log I see: -
Feb 4 10:38:08 morfsta vdr: [18340] probing /dev/dvb/adapter0/frontend0 Feb 4 10:38:08 morfsta vdr: [18340] device 1 provides: DVBS DSS Feb 4 10:38:08 morfsta vdr: [18344] tuner on device 1 thread started (pid=18340, tid=18344) Feb 4 10:38:08 morfsta vdr: [18345] section handler thread started (pid=18340, tid=18345) Feb 4 10:38:08 morfsta vdr: [18340] probing /dev/dvb/adapter1/frontend0 Feb 4 10:38:08 morfsta vdr: [18340] device 2 provides: DVBS DSS Feb 4 10:38:08 morfsta vdr: [18347] tuner on device 2 thread started (pid=18340, tid=18347) Feb 4 10:38:08 morfsta vdr: [18348] section handler thread started (pid=18340, tid=18348) Feb 4 10:38:08 morfsta vdr: [18340] probing /dev/dvb/adapter2/frontend0 Feb 4 10:38:08 morfsta vdr: [18340] device 3 provides: DVBS DVBS2 Feb 4 10:38:08 morfsta vdr: [18340] device 3 forced to frontendType SYS_DVBS2 Feb 4 10:38:08 morfsta vdr: [18350] tuner on device 3 thread started (pid=18340, tid=18350) Feb 4 10:38:09 morfsta vdr: [18351] section handler thread started (pid=18340, tid=18351)
which is funny because devices 0 and 1 are DVB-T:
[ 12.497993] DVB: registering adapter 0 frontend -858993460 (Philips TDA10045H DVB-T)... [ 12.554597] DVB: registering adapter 1 frontend -858993460 (Conexant CX22702 DVB-T)... [ 12.594872] DVB: registering adapter 2 frontend 0 (Conexant CX24116/CX24118)...
then when VDR starts tuning I see:
Feb 4 10:38:18 morfsta vdr: [18344] frontend 0 timed out while tuning to channel 1, tp 642 Feb 4 10:39:18 morfsta vdr: [18347] frontend 1 timed out while tuning to channel 1, tp 642 Feb 4 10:39:21 morfsta vdr: [18344] frontend 0 timed out while tuning to channel 1, tp 642
Any suggestions?
Thanks
On Wed, Feb 4, 2009 at 10:46 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Have you considered trying VDR 1.7.4?
Eek! Isn't that the one that even you don't consider using in a productive environment? ;-)
I'm not sure about the TS stuff and how that works and also that I won't be able to replay normal/HD recordings etc or whether it will work with VOMP or streamdev and all the other cool stuff I use. This is the problem for trying to use VDR/S2API etc in a productive environment with updated OS etc, it kind of leaves the users in a limbo where too much is being changed at once with implemented S2API *and* TS. :-(
I'm really confused now with where everything is at and what to do!
On 04.02.2009 11:52, Morfsta wrote:
On Wed, Feb 4, 2009 at 10:46 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Have you considered trying VDR 1.7.4?
Eek! Isn't that the one that even you don't consider using in a productive environment? ;-)
Well, even using *any* version 1.7.x in a productive environment is a risk ;-)
I'm not sure about the TS stuff and how that works and also that I won't be able to replay normal/HD recordings etc or whether it will work with VOMP or streamdev and all the other cool stuff I use. This is the problem for trying to use VDR/S2API etc in a productive environment with updated OS etc, it kind of leaves the users in a limbo where too much is being changed at once with implemented S2API *and* TS. :-(
S2API was necessary for HDTV channels, and recording HDTV channels only makes sense in TS. The PES recording of HDTV broadcasts was never officially supported by VDR.
Klaus
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Well, even using *any* version 1.7.x in a productive environment is a risk ;-)
[SNIP]
S2API was necessary for HDTV channels, and recording HDTV channels only makes sense in TS. The PES recording of HDTV broadcasts was never officially supported by VDR.
The other problem is that I don't think anyone has got VDR 1.7.4 working with the eHD yet, which is my output device... :-( So it seems everywhere I look at the moment I am stuck. :-(
Should VDR-1.7.0 be reporting my DVB-T frontends as DVBT when it starts up? Is there perhaps a capability flag in the driver that has not been setup for the devices that I am using? I compared the channel settings of BBC ONE in VDR with multiproto version and s2api version that I am running and they are exactly the same.
@Niels, which DVB-T devices are you using successfully with VDR-1.7.0 so that I can compare them with my own drivers? It seems strange though that scan-s2 successfully finds all the channels but VDR won't play them.
On Wednesday 04 of February 2009, Morfsta wrote:
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger
Klaus.Schmidinger@cadsoft.de wrote:
Well, even using *any* version 1.7.x in a productive environment is a risk ;-)
[SNIP]
S2API was necessary for HDTV channels, and recording HDTV channels only makes sense in TS. The PES recording of HDTV broadcasts was never officially supported by VDR.
The other problem is that I don't think anyone has got VDR 1.7.4 working with the eHD yet, which is my output device... :-( So it seems everywhere I look at the moment I am stuck. :-(
Hi,
I have it working with some dirty hacks (reelvdr svn 10388 - the latest with hdplayer). But for the problem with sending AC3 sound to ac3dec (with -a ac3dec) I didn't have enough time to solve. With sound over HDMI it could be used.
Ales
Should VDR-1.7.0 be reporting my DVB-T frontends as DVBT when it starts up? Is there perhaps a capability flag in the driver that has not been setup for the devices that I am using? I compared the channel settings of BBC ONE in VDR with multiproto version and s2api version that I am running and they are exactly the same.
@Niels, which DVB-T devices are you using successfully with VDR-1.7.0 so that I can compare them with my own drivers? It seems strange though that scan-s2 successfully finds all the channels but VDR won't play them.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Wednesday 04 of February 2009, Morfsta wrote:
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger
Klaus.Schmidinger@cadsoft.de wrote:
Well, even using *any* version 1.7.x in a productive environment is a risk ;-)
[SNIP]
S2API was necessary for HDTV channels, and recording HDTV channels only makes sense in TS. The PES recording of HDTV broadcasts was never officially supported by VDR.
The other problem is that I don't think anyone has got VDR 1.7.4 working with the eHD yet, which is my output device... :-( So it seems everywhere I look at the moment I am stuck. :-(
Here are patches for eHD and vdr-1.7.4. I've tested it only for a little time as I didn't have enough time (now I revert back to vdr-1.7.0 with multiproto).
Included are two patches - first is for reelbox plugin. In file ReelBoxDevice.c patch solves the audio problem (vdr is sending audio with zero trackid and reelbox plugin cancel such streams). In setupmenu.c is solved the problem with saving config and in VideoPlayerPipHd.c the include solves for me compile problem in amd64 linux.
In the patch for vdr in part of device.c is patch from Klaus for subtitles and rest is very quick and dirty patch for osd to compile with reelbox plugin. It mostly revert the vdr osd to 1.7.0 version of files, but it seems to be working at minimum with default STTNG skin, other skins are not tested.
Enjoy,
BR,
Ales
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Have you considered trying VDR 1.7.4?
Klaus, 1.7.4 works fine with S2API and DVB-T here....
Looks like there might be a problem in your patch somewhere Niels, but not sure where? I would still prefer to use 1.7.0 if possible, as expected a ton of plugins don't compile with 1.7.4... :-(
On Wednesday 04 February 2009, Klaus Schmidinger wrote:
On 04.02.2009 11:52, Morfsta wrote:
On Wed, Feb 4, 2009 at 10:46 AM, Klaus Schmidinger
Klaus.Schmidinger@cadsoft.de wrote:
Have you considered trying VDR 1.7.4?
Eek! Isn't that the one that even you don't consider using in a productive environment? ;-)
Well, even using *any* version 1.7.x in a productive environment is a risk ;-)
s/productive/production/, also in the developer version announcements, no?
-
Ales Jurik -
Klaus Schmidinger -
Morfsta -
Niels Wagenaar -
Ville Skyttä