Re: [vdr] Local frontend - using XBMC strm vs vdr-sxfe

[Simon Baxter]

On Fri, Mar 9, 2012 at 1:59 AM, Dominic Evans  wrote:
>
>
> I just wish I could have the full VDR OSD, but within XBMC :)
>

Yeah, shame about that.  It's unfortunate the development on XMBC isn't
anywhere as active or mature as VDR.

I recently got really lazy and installed yavdr-0.4 after 7 years running
everything from sources.  It's simplicity of use is great.  I use
xineliboutput to watch DVDs, movies and live/recordings of ATSC HD and only
use XBMC for all the web content (freecable, hulu etc).  Works pretty well
(apart from some regular xbmc crashing - which I really must look into at
some point).
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording

[Simon Baxter]

On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger <
klaus.schmidin...@tvdr.de> wrote:

> On 29.02.2012 12:44, Kende wrote:
>
>> On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
>>
>>> On 29.02.2012 12:13, Heikki Manninen wrote:
>>>
 I have a number of different Conax CAM modules from different
 manufacturers and all of them disappear from VDR after a couple of days
 running. Hitting CAM reset on the CI menu will bring it back "online".
 Naturally all Conax channel recordings will fail silently as a result of
 this until the CAM has been brought back up. Switching to an encrypted
 channel just gives the standard "channel not available" message.

 This happens (for me) with Satelco DVB-C card with Satelco CI. From
 what I understand, this seems to be a common problem though I'm not sure
 whether it is limited to Satelco devices only.

 Would it be possible to force CAM reset on all CI slots when VDR is
 trying to start recording non-FTA channel?

>>>
>>> Wouldn't it be better to fix the actual problem and prevent
>>> the CAM from "disappearing"?
>>>
>>
>> Hola,
>>
>> For me this seems to be driver issue, not VDRs fault. CI poll ioctl write
>> seems to fail sometimes with my KNC One (saa7146) budget cards . Following
>> patch seems to help in my case:
>>
>> --- dvbci.c 2007-01-04 14:49:10.0 +0200
>> +++ ../vdr-1.7.21/dvbci.c   2011-10-12 10:49:45.689684447 +0300
>> @@ -62,8 +62,10 @@
>>  void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
>>  {
>>if (Buffer&&  Length>  0) {
>>
>> - if (safe_write(fd, Buffer, Length) != Length)
>> +if (safe_write(fd, Buffer, Length) != Length) {
>>  esyslog("ERROR: can't write to CI adapter on device %d: %m",
>> device->De
>> viceNumber());
>> +   Reset(device->DeviceNumber());
>> +}
>>   }
>>  }
>>
>
> I tried this, but I'm afraid it doesn't help.
> The Reset() call was never triggered, even though my CAM went from normal
> operation to the "CAM ready" state, and not even an explicit reset via
> the Setup/CAM menu brought it to life again. Only after reloading the
> driver and restarting VDR did it work again.
>
> My theory is that switching channels is what's causing the problem.
> When I trigger an EPG scan, the problem typically occurs after a while.
> Maybe it's caused by tuning to channels that are no longer available,
> so the frontend times out. However, there's no reason why a frontend
> timeout should lead to a CAM freeze...
>
>
I've had this problem for years on my TT-2300-C-FF and TT-1501-C cards with
Alphacrypt Multicam.  Updating the CAM has no effect, same experience with
multiple versions of VDR.  Most of the time the CAM can be brought back to
"Ready" by doing a CAM Reset from the VDR menus multiple times.  On rare
occasions the CAM will still be "Ready" but I still get "Channel not
available", until I do a CAM reset a few times.

I have a crude script which looks for "ERROR: can't write to CI adapter on
device" in the syslog which notifies me so I can do the "CAM reset" (often
multiple times) from the VDR menus.

This appears to be either a bug in the dvb code - which has never been
fixed.  To be honest - it's nice to hear other people have had the problem!!
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ATSC Channel providers California

[Simon Baxter]

Have a look here:


http://www.silicondust.com/support/channels

Once you've selected your zip code, it will tell you what you have via 
ATSC over the air, and ATSC-Qam through your cable companies.


I have some scripts which use this to build a channels.conf if you'd 
like..


Any chance I could get hold of those scripts to build channels.conf?

I'm now in Portland Oregon, zip 97224


Thanks
Simon


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] preventing vdr from using a device torecord

[Simon Baxter]

Hi,

Am 16.04.2011 16:28, schrieb syrius...@no-log.org:


I'm now running one vdr instance with 4 dvb devices.
One device is crashing quite often and I haven't find a way to
automatically detect when it's crashed. (vdr used to issues "unknown
picture type message in the past)

I'd like to prevent vdr from using it for recordings.
Do you know of any plugin or patch that help achieving this ?

Ideally I'd love to be able to set priorities and properties to
devices.
Something like:
device #1: can_record, can_do_epg_scan, can_do_liveview, devprio=100
device #2: can_record, can_do_epg_scan, can_do_liveview, devprio=90
device #3: can_do_liveview, devprio=10

Is there a way for plugins to alter *cDevice::GetDevice behavior ?
Are there any plans on that matter ?


Please modify the attached plugin, telling that device 3 doesn't
provide any transponder.



Would this also work if only a CAM device has crashed?  I have multiple 
DVB-C cards each with their own CAM.  Occasionally the CAM either crashes to 
"CAM Ready" state (rather than "Alphacrypt" in the CAM menu) or just fails 
to respond - either way, the CAM needs often multiple RESETS from the CAM 
menu.





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ATSC Channel providers California (now OREGON

[Simon Baxter]

From what I've read Comcast uses two levels of encryption, a basic one
for tier one channels (extended basic in marketing terms) then a more 
comprehensive key encryption for their digital preferred channels.


I use a combination of two set top boxes, a PVR HD for HD channels and a 
PVR500 for SD channels, and two Clear Qam adapters for locals.


The Clear Qam are very good quality MPEG 2 HD or SD streams with AC3 
audio, the PVR500 is reasonable, but one my boxes has interference on the 
svideo output.


The HD-PVR is really good, giving an H264 with AC-3 passthrough TS 
stream. However, every now and then the cable box glitches and the HD-PVR 
stops streaming.  PVRInput isn't aware (yet - although Lars is looking 
into it) that it's not sending anything to VDR.  This is a problem when 
recording as VDR restarts, if I'm doing concurrent recordings then I lose 
bits of other recording during this time.  As an aside, AC-3 is passed 
through from the original ATSC-QAM stream, I had to patch VDR again to 
stop checking for ATSC on Audio Type 0x81 or VDR would ignore the audio 
dpid of the channel and set it to 0.  This also had to be done for the 
VNSI plugin in XBMC-PVR.


I really want to thank Lars for teaching me about TS streams..


New question - what hardware support is there for VDR and ATSC?  I'm moving
to the US, so will be ditching my DVB-C and DVB-S hardware - what should I
be buying to work with VDR?






___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17

[Simon Baxter]

On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter  
wrote:

Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error
messages.

Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode


Those aren't error messages, they're just information messages from 
vdr-xine.




Sorry, forgot to mention - I'm getting severe video slipping.  The audio 
sounds OK, but the video skips every few seconds as per the timestamps:


Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17

[Simon Baxter]

Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error 
messages.




Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:09:01 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:09:01 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:09:09 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:09:09 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:09:14 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:09:14 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode
Mar 14 20:09:18 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 
mode
Mar 14 20:09:18 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 
mode



I see there were some few changes in remux.c - any thoughts?

The only patch I've implemented in both vdr-1.7.16 and vdr-1.7.17 is as 
follows, to get around a problem decoding my dvb-c channels:


# diff device.c.orig device.c
1502,1513c1502,1513
< if (CamSlotNumber) {
 TS_SCRAMBLING_TIMEOUT)
<  DetachReceivers = true;
<   }
 TS_SCRAMBLING_TIME_OK) {
<   DescramblingOk = true;
<   startScrambleDetection = 0;
<   }
<}
---

//SBB if (CamSlotNumber) {
//   bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
//   int t = time(NULL) - startScrambleDetection;
//   if (Scrambled) {
//  if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
//  }
//   else if (t > TS_SCRAMBLING_TIME_OK) {
//  DescramblingOk = true;
//  startScrambleDetection = 0;
//  }
//   }




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] How's the 24 bit OSD VDR coming?

[Simon Baxter]

Hi Klaus - et al

How's the development on vdr-1.7.17 (?) coming?  I wait with baited breath!! 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Replacing aging VDR for DVB-S2

[Simon Baxter]

I've avoided the noise problem by putting the VDR under the stairs
where it can make as much noise as it likes.  There it plugs in to a
X-VGA splitter/broadcaster which sends duplicate signals over CAT-5
to each TV, where another small STB converts the signal back in to
VGA.  I've also put Infrared extenders everywhere.  Result - a TV
with no other hardware visible: no cables, no equipment, nothing.
Just a TV on a wall bracket. Wife happy!


Does that work with HD without much quality compromise?


The VGA adapter I bought supports my TV which does 1366x768 just fine.  It 
will also do 1920 resolution (I think) but my TV won't do that anyway.


Picture is perfect - no complaints.  Only thing my setup won't do is 
different front ends - but I have no need to watch different things in 
different rooms.




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Replacing aging VDR for DVB-S2

[Simon Baxter]

Indeed they do.  I'm particular about noise as I use htpc's with my
televisions.  I don't want to watch something and have to listen to a
fan.  If I can barely hear a fan with the tv off, that is acceptable
but it must be very low noise.


I've avoided the noise problem by putting the VDR under the stairs where it 
can make as much noise as it likes.  There it plugs in to a X-VGA 
splitter/broadcaster which sends duplicate signals over CAT-5 to each TV, 
where another small STB converts the signal back in to VGA.  I've also put 
Infrared extenders everywhere.  Result - a TV with no other hardware 
visible: no cables, no equipment, nothing.  Just a TV on a wall bracket. 
Wife happy!





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Developer versions

[Simon Baxter]

AIUI VDR generates the OSD as a bitmap no matter which output plugin is
used and the player only has the choice of how to overlay it on the
video. So getting it rendered by VDPAU would be easy enough, but to
upgrade it to HD would probably need some rewriting/patching in core
VDR, not just a plugin. I think the ability to antialias the text would
be the biggest improvement, it often looks jagged.


The next developer version of VDR will contain full True-Color OSD 
support.

I'm in the final stages of implementing all that's necessary to do that,
like background image, transparent and movable overlayed pixmaps and
the like.

Klaus



Wow!  The world may be changing!!

Will this be a 1.8 release, or still in the 1.7 development train?

Any ETA? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] CAM auto resetting - feature request??

[Simon Baxter]

Btw, I'm not sure if I mentioned, but this is happening in VDR 1.6, and I 
belive Halim has it on 1.7? So it has been around for quite a while. I can 
try patches if needed, as it should be pretty straight forward applying 
them on Gentoo, but 1.6 would be prefered.


Yip - I've been experiencing this since 1.6, and kernels from 2.6.24 thru 
2.6.33.


Have tried manipulating the kernel source (dvb_ca_en50221.c) and adding 
breaks to extend wait times between READ/WRITE transactions to the CAM 
(multiple 'msleep(1);' commands).  Used to help with earlier kernels, but 
has no affect for the past 2 years.


As I've mentioned before, I don't know what else to try.

Here's the problems I have with my CAM decryptions

* intermittant CAM crash, going from 'Alphacrypt' to 'CAM Ready'
* intermittant CAM lock out.  Can't access CAM menu, but CAM still displays 
'Alphacrypt'


Both respond to reset (or multiple, up to 10 resets) and CAM comes back.

My system has 2 identical CAMs.  Problem only affects one at a time, but 
does affect both.


Also occurs in CAM versions 3.09 thru 3.16 (tried upgrading/downgrading).



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xine ui - small black bar on top

[Simon Baxter]

Hi

I'm intermittantly getting a 1cm black bar at the top of the screen in 
xine.


I'm using vdr-xine version 0.9.3 with xine-lib-1.2, with a standard 
xine-ui front end and vdr-1.7.16.


The black bar has a small white verticle line on the far right. Other 
than pushing the whole picture down 1cm, it has no other effect.


When X first starts, and xine launches, the black bar isn't there. If I 
exit the xine front end and restart (without restarting vdr) it appears 
and won't go until X restarts again.


Any ideas?




I'm guessing here that your window manager loads after the first time
xine-ui loaded and that your xine-ui is not in fullscreen mode. Try
double clicking (left button) on the screen to see if that makes it go
away? Or have a look at the place where xine-ui is called from. To see
if the fullscreen parameter was added.


Not quite.

1. My window manager (fluxbox) starts.
2. I then manually start xine with:
xine --no-splash -Bfpqg --hide-gui -r anamorphic -V 
xv -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 
--post vdr_video --post vdr_audio vdr://tmp/vdr-xine/stream#demux:mpeg_pes

xine-ui starts fine with no black bars
3. I kill the xine process (above), or hit CTRL-C (either)
4. manually start xine 2. above
xine-ui starts, but the single black 1cm bar at the top of the fullscreen 
xine is visible


any more thoughts? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] CAM auto resetting - feature request??

[Simon Baxter]

On 12/23/10 00:14, Simon Baxter wrote:

hello Klaus,

I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect
ct-3650
I used a alphacrypt light and I also tried the classic module

always the same behavior - if I zap from encrypted channel to
encrypted channel in some situations vdr says "channel not available"
if I reset the cam manually it works again immediately
I also tried vdr 1.4 with my old tt ff c2300 and I had no problems

maybe its a general vdr 1.7.x cam handling problem

any idea - what I can do or test to identify where the problem is?

thanks


I had assumed this was due to some problem with CAM keys from the
provider expiring, or something.  I still intermittantly get "channel
not available", but haven't found any way to recreate the problem at
will.

I have exactly this aswel. It happens from 'surfing channels'. Never
happens while watching the same channel continuously. Cannot say for
sure it doesn't happen when surfing within the same bouquet.


I have multiple cards, 2x DVB-C+CAM, 2xDVB-S FTA.  I sometimes get these 
messages when watching FTA too, when encrypted channels are recording and 
changing in the background.





I also occasionally have a CAM crash - where the status in goes from
"ALPHACRYPT" to "CAM PRESENT" or "CAM READY".  A manual reset (or
multiple) fixes this, but I get no decryption during a "crash".

Yep, also this, only for "Conax Conditional Acess". Resetting it works
best when using an FTA channel it seems.


...problems I've had to live with for months.  Gave up asking and
installed an FTA satellite dish for 50% of my mostly watched channels.

I'm looking at an oscam solution right now, but need to get a proper
card reader, or try to get my old towitoko chipdrive going.


Don't know anything about oscam... 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] xine ui - small black bar on top

[Simon Baxter]

Hi

I'm intermittantly getting a 1cm black bar at the top of the screen in xine.

I'm using vdr-xine version 0.9.3 with xine-lib-1.2, with a standard xine-ui 
front end and vdr-1.7.16.


The black bar has a small white verticle line on the far right.  Other than 
pushing the whole picture down 1cm, it has no other effect.


When X first starts, and xine launches, the black bar isn't there.  If I 
exit the xine front end and restart (without restarting vdr) it appears and 
won't go until X restarts again.


Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] CAM auto resetting - feature request??

[Simon Baxter]

hello Klaus,

I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650
I used a alphacrypt light and I also tried the classic module

always the same behavior - if I zap from encrypted channel to encrypted 
channel in some situations vdr says "channel not available"

if I reset the cam manually it works again immediately
I also tried vdr 1.4 with my old tt ff c2300 and I had no problems

maybe its a general vdr 1.7.x cam handling problem

any idea - what I can do or test to identify where the problem is?

thanks


I had assumed this was due to some problem with CAM keys from the provider 
expiring, or something.  I still intermittantly get "channel not available", 
but haven't found any way to recreate the problem at will.


I also occasionally have a CAM crash - where the status in goes from 
"ALPHACRYPT" to "CAM PRESENT" or "CAM READY".  A manual reset (or multiple) 
fixes this, but I get no decryption during a "crash".


...problems I've had to live with for months.  Gave up asking and installed 
an FTA satellite dish for 50% of my mostly watched channels. 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)

[Simon Baxter]

Dec 16 17:58:55 erin vdr: [2756] switching to channel 42
Dec 16 17:58:55 erin vdr: [2884] transfer thread ended (pid=2756, 
tid=2884)

Dec 16 17:58:55 erin vdr: [2756] buffer stats: 40232 (1%) used
Dec 16 17:58:55 erin vdr: [2888] transfer thread started (pid=2756,
tid=2888)
Dec 16 17:58:55 erin vdr: [2887] osdteletext-receiver thread ended
(pid=2756, tid=2887)
Dec 16 17:58:55 erin vdr: [2756] buffer stats: 0 (0%) used
Dec 16 17:58:55 erin vdr: [2889] osdteletext-receiver thread started
(pid=2756, tid=2889)
Dec 16 17:58:56 erin vdr: [2888] [xine..put] Detected video size 704x576
Dec 16 17:58:56 erin vdr: [2888] setting audio track to 1 (0)
Dec 16 17:58:59 erin vdr: [2756] switching to channel 64
Dec 16 17:58:59 erin vdr: [2888] transfer thread ended (pid=2756, 
tid=2888)

Dec 16 17:58:59 erin vdr: [2756] buffer stats: 75388 (3%) used
Dec 16 17:58:59 erin vdr: [2889] osdteletext-receiver thread ended
(pid=2756, tid=2889)
Dec 16 17:58:59 erin vdr: [2890] transfer thread started (pid=2756,
tid=2890)
Dec 16 17:59:00 erin vdr: [2886] TS buffer on device 1 thread ended
(pid=2756, tid=2886)
Dec 16 17:59:00 erin vdr: [2885] buffer stats: 78960 (3%) used
Dec 16 17:59:00 erin vdr: [2885] receiver on device 1 thread ended
(pid=2756, tid=2885)
Dec 16 17:59:00 erin vdr: [2891] receiver on device 1 thread started
(pid=2756, tid=2891)
Dec 16 17:59:00 erin vdr: [2756] buffer stats: 0 (0%) used
Dec 16 17:59:00 erin vdr: [2756] creating directory
/var/cache/osdteletext/T-8720-2213-32
Dec 16 17:59:00 erin vdr: [2893] TS buffer on device 1 thread started
(pid=2756, tid=2893)
Dec 16 17:59:00 erin vdr: [2892] osdteletext-receiver thread started
(pid=2756, tid=2892)
Dec 16 17:59:01 erin vdr: [2756] retuning due to modification of channel 
64

Dec 16 17:59:01 erin vdr: [2756] switching to channel 64
Dec 16 17:59:01 erin vdr: [2890] transfer thread ended (pid=2756, 
tid=2890)

Dec 16 17:59:01 erin vdr: [2756] buffer stats: 39480 (1%) used
Dec 16 17:59:01 erin vdr: [2894] transfer thread started (pid=2756,
tid=2894)
Dec 16 17:59:04 erin vdr: [2756] switching to channel 42


any idea why the scrambled stream isn't being decoded?


Have you tried turning on debugging in ci.c?
// Set these to 'true' for debug output:
static bool DumpTPDUDataTransfer = false;
static bool DebugProtocol = false;
static bool DumpPolls = false;
static bool DumpDateTime = false;


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] CAM auto resetting - feature request??

[Simon Baxter]

Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
device 0: Input/output error
Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
initialised successfully


This looks more like a driver bug to me.


Well maybe but unfortunately responds to my mails in linux-dvb /
linux-media mailinglist for that problem.

@Klaus:
If that problem happens, a manual reset of the cam under vdr's
menu->settings->ci brings the cam back.

What about trying to reset a cam automatically when it's Status is !=
msReady?

Like this:
diff --git a/device.c b/device.c
index 681049b..7904de2 100644
--- a/device.c
+++ b/device.c
@@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, 
int Priority, bool LiveView

   if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
  for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = 
CamSlots.Next(CamSlot)) {
  SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it 
can't be used

+ if (CamSlot->ModuleStatus() == msPresent)
+CamSlot->Reset();
  if (CamSlot->ModuleStatus() == msReady) {
 if (CamSlot->ProvidesCa(Channel->Caids())) {
if 
(!ChannelCamRelations.CamChecked(Channel->GetChannelID(), 
CamSlot->SlotNumber())) {


Have you tested this?
Did it actually work?

Klaus


Will give it a try and report back 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] dvbsddevice-Plugin: Problems with A/V Sync

[Simon Baxter]

Ah.  Can't help you then, sorry!
  - Original Message - 
  From: Christopher Reimer 
  To: VDR Mailing List 
  Sent: Sunday, November 28, 2010 7:10 AM
  Subject: Re: [vdr] dvbsddevice-Plugin: Problems with A/V Sync


  2010/11/25 Simon Baxter 

I had some problems with vdr-1.7.x and vdr-xine front end with audio sync, 
but fixed them in xine.





  Frontend??? I'm using a Technotrend Full-Featured Card. So the backend is the 
Full-Featured Card and the frontend, too



--


  ___
  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] dvbsddevice-Plugin: Problems with A/V Sync

[Simon Baxter]

I had some problems with vdr-1.7.x and vdr-xine front end with audio sync, but 
fixed them in xine.

What front end are you using?
  - Original Message - 
  From: Christopher Reimer 
  To: vdr@linuxtv.org 
  Sent: Thursday, November 25, 2010 7:50 AM
  Subject: [vdr] dvbsddevice-Plugin: Problems with A/V Sync


  Hi everyone,

  I am using vdr version 1.7.16 and I have discovered some A/V Sync problems 
after jumping to another mark or jumping with the yellow/green button.

  Is that an already-known-problem?



--


  ___
  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] xmltv2vdr does not with VDR 1.7.16??

[Simon Baxter]

Suggest you run it against a cut down channels.conf (with maybe just one 
channel) and with the -s switch to simulate output.


Have a look at the EPG commands created and see if they work manually 
(telnet 127.0.0.1 6419)




Works fine for me on vdr-1.7.16


- Original Message - 
From: "semsem85 sami" 

To: 
Sent: Monday, November 01, 2010 3:44 AM
Subject: [vdr] xmltv2vdr does not with VDR 1.7.16??




Hi,

The xmltv2vdr script is not working for me on VDR 1.7.16. There is no EPG 
on the target channels.

Anybody can confirm if it is working for you or not. Thanks a lot.


BTW, I know I should run the scrip with the -p parameter as SDVRP port in 
VDR has changed, but the script runs without error and no EPG is shown.


Best Regards

Sami







___
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




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xmltv2vdr does not with VDR 1.7.16??

[Simon Baxter]

Works fine for me on vdr-1.7.16


- Original Message - 
From: "semsem85 sami" 

To: 
Sent: Monday, November 01, 2010 3:44 AM
Subject: [vdr] xmltv2vdr does not with VDR 1.7.16??




Hi,

The xmltv2vdr script is not working for me on VDR 1.7.16. There is no EPG 
on the target channels.

Anybody can confirm if it is working for you or not. Thanks a lot.


BTW, I know I should run the scrip with the -p parameter as SDVRP port in 
VDR has changed, but the script runs without error and no EPG is shown.


Best Regards

Sami







___
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] Why won't my new TT-1401 DVB-S work [RESOLVED]

[Simon Baxter]

Can anyone help me on my problem?

I've found I can get a picture with "mplayer /dev/dvb/adapter0/dvr0" when 
I szap, BUT only if I add the "-r" switch


szap -r -l 11300 -c /etc/vdr/vdr-1.7.15/channels.conf "Maori TV"

1) If I miss out the "-r" switch I can't get a picture from dvr0.
2) If I add the "-r" switch, mplayer detects the TS format and plays the 
live TV perfectly.

3) If I miss out the "-l 11300" I can't get the front end to lock

I still can't get the front end to lock in VDR either - so no recording 
and no live TV.


I've tried all sorts of LNB config in setup.conf - latest being:
Use DiSEqC:no
SLOF (MHz):11700
Low LNB frequency (MHz):   9750
High LNB frequency (MHz):  10600

But I can't get it to work.


Any ideas?


Had to use a diseqc.conf entry, even though I'm not actually using diseqc!

S160E 9 H 11300 t V

All good now 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Why won't my new TT-1401 DVB-S work :(

[Simon Baxter]

Can anyone help me on my problem?

I've found I can get a picture with "mplayer /dev/dvb/adapter0/dvr0" when I 
szap, BUT only if I add the "-r" switch


szap -r -l 11300 -c /etc/vdr/vdr-1.7.15/channels.conf "Maori TV"

1) If I miss out the "-r" switch I can't get a picture from dvr0.
2) If I add the "-r" switch, mplayer detects the TS format and plays the 
live TV perfectly.

3) If I miss out the "-l 11300" I can't get the front end to lock

I still can't get the front end to lock in VDR either - so no recording and 
no live TV.


I've tried all sorts of LNB config in setup.conf - latest being:
Use DiSEqC:no
SLOF (MHz):11700
Low LNB frequency (MHz):   9750
High LNB frequency (MHz):  10600

But I can't get it to work.


Any ideas?



But I'm still getting:

Oct  8 07:34:21 callin vdr: [1677] saved setup to 
/etc/vdr/vdr-1.7.15/setup.conf

Oct  8 07:34:27 callin vdr: [1677] switching to channel 1
Oct  8 07:34:30 callin vdr: [1681] frontend 0/0 timed out while tuning to 
channel 1, tp 112483
Oct  8 07:35:35 callin vdr: [1681] frontend 0/0 timed out while tuning to 
channel 1, tp 112483



And I can still szap:
./szap -l 11300 -c /etc/vdr/vdr-1.7.15/channels.conf "Maori TV"
reading channels from file '/etc/vdr/vdr-1.7.15/channels.conf'
zapping to 1 'Maori TV':
sat 0, frequency = 12483 MHz H, symbolrate 2250, vpid = 0x0202, apid = 
0x028c sid = 0x

using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 03 | signal c94f | snr 95c4 | ber ff17 | unc fffe |
status 1f | signal ca5e | snr 9537 | ber 0600 | unc fffe | 
FE_HAS_LOCK
status 1f | signal ca76 | snr 95d6 | ber 0700 | unc fffe | 
FE_HAS_LOCK
status 1f | signal c940 | snr 95a9 | ber 0600 | unc fffe | 
FE_HAS_LOCK
status 1f | signal ca7e | snr 9558 | ber 0600 | unc fffe | 
FE_HAS_LOCK





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Why won't my DVB-S work?

[Simon Baxter]

En/na Simon Baxter ha escrit:


My setup.conf for the LNB has:
LnbFrequHi = 11300
LnbFrequLo = 10750
LnbSLOF = 12500


If that's an universal lnb the correct settings are

LnbFrequHi = 10600
LnbFrequLo = 9750
LnbSLOF = 11700


Changed LNB settings to:
Use DiSEqC:no
SLOF (MHz):11700
Low LNB frequency (MHz):   9750
High LNB frequency (MHz):  10600

But I'm still getting:

Oct  8 07:34:21 callin vdr: [1677] saved setup to 
/etc/vdr/vdr-1.7.15/setup.conf

Oct  8 07:34:27 callin vdr: [1677] switching to channel 1
Oct  8 07:34:30 callin vdr: [1681] frontend 0/0 timed out while tuning to 
channel 1, tp 112483
Oct  8 07:35:35 callin vdr: [1681] frontend 0/0 timed out while tuning to 
channel 1, tp 112483


channels.conf:
cat /etc/vdr/vdr-1.7.15/channels.conf
Maori TV:12483:h:S160.0E:22500:514:652:0:0:1025:47:22:0

Devicestatus says:
--- Device 1 -- Live  (primary device) ---
satellite card (ST STV0299 DVB-S) - /dev/dvb/adapter0/frontend0
frequency: 12483 MHz, signal: 60%, s/n: 44%
currently no recordings
   1  t +  Maori TV  ()


And I can still szap:
./szap -l 11300 -c /etc/vdr/vdr-1.7.15/channels.conf "Maori TV"
reading channels from file '/etc/vdr/vdr-1.7.15/channels.conf'
zapping to 1 'Maori TV':
sat 0, frequency = 12483 MHz H, symbolrate 2250, vpid = 0x0202, apid = 
0x028c sid = 0x

using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 03 | signal c94f | snr 95c4 | ber ff17 | unc fffe |
status 1f | signal ca5e | snr 9537 | ber 0600 | unc fffe | 
FE_HAS_LOCK
status 1f | signal ca76 | snr 95d6 | ber 0700 | unc fffe | 
FE_HAS_LOCK
status 1f | signal c940 | snr 95a9 | ber 0600 | unc fffe | 
FE_HAS_LOCK
status 1f | signal ca7e | snr 9558 | ber 0600 | unc fffe | 
FE_HAS_LOCK


but no picture!

Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Why won't my DVB-S work?

[Simon Baxter]

Hi

I've added a DVB-S card to my vdr-1.7.16, but I can't get a picture.

I can do an szap as follows:
TV3:12456:h:0:22500:512:650:1920

./szap -l 11300 -c channels-conf/dvb-s/OptusD1E160 TV3
reading channels from file 'channels-conf/dvb-s/OptusD1E160' zapping to 1 
'TV3':
sat 0, frequency = 12456 MHz H, symbolrate 2250, vpid = 0x0200, apid = 
0x028a sid = 0x0780

using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 1f | signal cd82 | snr be5c | ber ff00 | unc fffe | 
FE_HAS_LOCK
status 1f | signal ccf8 | snr bccd | ber  | unc fffe | 
FE_HAS_LOCK
status 1f | signal cd03 | snr bcbe | ber  | unc fffe | 
FE_HAS_LOCK
status 1f | signal cd0b | snr bc6a | ber  | unc fffe | 
FE_HAS_LOCK



I can do a scan:
./scan -c -o vdr
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
Network Name 'Freeview'
0x0016 0x0794: pmt_pid 0x0122 TVWORKS -- C42 (running)
0x0016 0x0787: pmt_pid 0x0121 Kordia Limited -- Shine TV (running)
0x0016 0x078f: pmt_pid 0x0119 GeorgeFM -- GeorgeFM (running)
0x0016 0x0786: pmt_pid 0x0110 TVWORKS  -- TV3 PLUS1 (running)
0x0016 0x0780: pmt_pid 0x010a TV Works -- TV3 (running)
0x0016 0x0781: pmt_pid 0x010b TV Works -- C4 (running)
0x0016 0x0782: pmt_pid 0x010c STRATOS Limited -- STRATOS (running)
0x0016 0x0783: pmt_pid 0x010d Kordia Limited -- Parliament TV (running)
0x0016 0x0784: pmt_pid 0x010e Kordia Limited -- CUE (running)
0x0016 0x0785: pmt_pid 0x010f Maori Television Service -- Te Reo (running)
0x0016 0x0789: pmt_pid 0x0113 Radio New Zealand -- RNZ National (running)
0x0016 0x078a: pmt_pid 0x0114 Radio New Zealand -- RNZ Concert (running)
0x0016 0x0790: pmt_pid 0x011a Kordia -- BaseFM (running)
0x0016 0x0788: pmt_pid 0x0112 SKY -- PRIME (running)
dumping lists (15 services)
TV3;TV Works:12483:h:S160.0E:22500:512:650:712:0:1920:47:22:0
C4;TV Works:12483:h:S160.0E:22500:513:651:0:0:1921:47:22:0
TV3 PLUS1;TVWORKS :12483:h:S160.0E:22500:518:656:0:0:1926:47:22:0
C42;TVWORKS:12483:h:S160.0E:22500:531:674:0:0:1940:47:22:0
PRIME;SKY:12483:h:S160.0E:22500:520:658=eng:0:0:1928:47:22:0
Parliament TV;Kordia 
Limited:12483:h:S160.0E:22500:515:653=eng,690=ang:0:0:1923:47:22:0

CUE;Kordia Limited:12483:h:S160.0E:22500:516:654=eng:0:0:1924:47:22:0
Te Reo;Maori Television 
Service:12483:h:S160.0E:22500:517:655=eng:0:0:1925:47:22:0

Shine TV;Kordia Limited:12483:h:S160.0E:22500:530:673=eng:0:0:1927:47:22:0
STRATOS;STRATOS Limited:12483:h:S160.0E:22500:514:652=eng:0:0:1922:47:22:0
RNZ National;Radio New 
Zealand:12483:h:S160.0E:22500:0:659=eng:0:0:1929:47:22:0
RNZ Concert;Radio New 
Zealand:12483:h:S160.0E:22500:0:660=eng:0:0:1930:47:22:0

[078b];(null):12483:h:S160.0E:22500:0:661=eng:0:0:1931:47:22:0
GeorgeFM;GeorgeFM:12483:h:S160.0E:22500:0:665=eng:0:0:1935:47:22:0
BaseFM;Kordia:12483:h:S160.0E:22500:0:666=eng:0:0:1936:47:22:0
Done.

My setup.conf for the LNB has:
LnbFrequHi = 11300
LnbFrequLo = 10750
LnbSLOF = 12500

But vdr reports:
Oct  7 15:10:29 callin vdr: [2039] frontend 0/0 timed out while tuning to 
channel 1, tp 112483



Any ideas?  What am I missing?




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ATSC Channel providers California

[Simon Baxter]

Do any networks or network providers provide free or accessible ATSC
channels in the LA area?

Is it FTA, or do they require a CI/CAM?


Have a look here:


http://www.silicondust.com/support/channels

Once you've selected your zip code, it will tell you what you have via 
ATSC over the air, and ATSC-Qam through your cable companies.


I have some scripts which use this to build a channels.conf if you'd 
like..


Thanks Rob

Is there a CI/CAM option with ATSC-QAM cards?  Or are the cable network 
encryption mechanisms proprietary (needing PVR with HDMI to get into VDR)? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] ATSC Channel providers California

[Simon Baxter]

Do any networks or network providers provide free or accessible ATSC 
channels in the LA area?


Is it FTA, or do they require a CI/CAM? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] LNB settings - what should they be?

[Simon Baxter]

My dvb-s LNB is a Ku-Band LNBG DKF-2024.

The box says:
Input 11.70-12.50 Ghz
L.O. 10.75 Ghz
Noise 0.6dB
Gain 60dB

If I set VDR up as follows:
Use DiSEqC:no
SLOF (MHz):10750
Low LNB frequency (MHz):   11700
High LNB frequency (MHz):  12500
No idea, just guessing, try rearranging your values in the same sort order 
a my 'it works for me' section,


High LNB frequency (MHz):  11700
Low LNB frequency (MHz):   10750
High LNB frequency (MHz):  12500

When I change channels I get:
Sep 25 21:15:18 localhost vdr: [2058] ERROR: frontend 0/0: Invalid 
argument
Sep 25 21:15:18 localhost kernel: DVB: adapter 0 frontend 0 frequency 
12456000 out of range (95..215)




Thanks - changed my settings to:
Use DiSEqC:no
SLOF (MHz):12500
Low LNB frequency (MHz):   10750
High LNB frequency (MHz):  11700

and I no longer the the "out of range error" which is progress I guess!!

But I still get these errors and no picture on any channels:
Sep 26 08:38:28 localhost vdr: [1531] switching to channel 2
Sep 26 08:38:30 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 2, tp 112456
Sep 26 08:39:35 localhost vdr: [1531] ERROR: /var/cache/vdr/epg.data.$$$: No 
such file or directory
Sep 26 08:39:35 localhost vdr: [1531] ERROR (epg.c,1160): No such file or 
directory
Sep 26 08:39:38 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 16, tp 112483

Sep 26 08:39:58 localhost vdr: [1531] switching to channel 3
Sep 26 08:40:08 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 3, tp 112456

Sep 26 08:40:08 localhost vdr: [1531] switching to channel 4
Sep 26 08:40:17 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 4, tp 112456

Sep 26 08:40:18 localhost vdr: [1531] switching to channel 5
Sep 26 08:40:26 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 5, tp 112456

Sep 26 08:40:27 localhost vdr: [1531] switching to channel 6
Sep 26 08:40:36 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 6, tp 112456

Sep 26 08:40:36 localhost vdr: [1531] switching to channel 7
Sep 26 08:40:45 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 7, tp 112456

Sep 26 08:40:46 localhost vdr: [1531] switching to channel 8
Sep 26 08:40:54 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 8, tp 112456

Sep 26 08:40:55 localhost vdr: [1531] switching to channel 9
Sep 26 08:41:03 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 9, tp 112456

Sep 26 08:41:04 localhost vdr: [1531] switching to channel 10
Sep 26 08:41:13 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 10, tp 112456

Sep 26 08:41:13 localhost vdr: [1531] switching to channel 11
Sep 26 08:41:22 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 11, tp 112456

Sep 26 08:41:23 localhost vdr: [1531] switching to channel 12
Sep 26 08:41:31 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 12, tp 112456

Sep 26 08:41:32 localhost vdr: [1531] switching to channel 13
Sep 26 08:41:41 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 13, tp 112456

Sep 26 08:41:41 localhost vdr: [1531] switching to channel 14
Sep 26 08:41:50 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 14, tp 112456

Sep 26 08:41:51 localhost vdr: [1531] switching to channel 15
Sep 26 08:41:59 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 15, tp 112456

Sep 26 08:42:00 localhost vdr: [1531] switching to channel 16
Sep 26 08:42:09 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 16, tp 112483

Sep 26 08:42:10 localhost vdr: [1531] switching to channel 17
Sep 26 08:42:19 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 17, tp 112483

Sep 26 08:42:19 localhost vdr: [1531] switching to channel 18
Sep 26 08:42:28 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 18, tp 112483

Sep 26 08:42:28 localhost vdr: [1531] switching to channel 19
Sep 26 08:42:37 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 19, tp 112483

Sep 26 08:42:38 localhost vdr: [1531] switching to channel 20
Sep 26 08:42:47 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 20, tp 112483

Sep 26 08:42:48 localhost vdr: [1531] switching to channel 21
Sep 26 08:42:56 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 21, tp 112483

Sep 26 08:42:56 localhost vdr: [1531] switching to channel 22
Sep 26 08:43:05 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 22, tp 112483

Sep 26 08:43:06 localhost vdr: [1531] switching to channel 23
Sep 26 08:43:15 localhost vdr: [1535] frontend 0/0 timed out while tuning to 
channel 23, tp 112483


My channels.conf is:
TV3;TV Works:12456:hM2O0S0:S160.0E:22500:512=2:6...@4:712:0:1920:47:21:0
C4;TV Works:12456:h:S160.0E:22500:513=2:6...

[vdr] LNB settings - what should they be?

[Simon Baxter]

Hi

My dvb-s LNB is a Ku-Band LNBG DKF-2024.

The box says:
Input 11.70-12.50 Ghz
L.O. 10.75 Ghz
Noise 0.6dB
Gain 60dB

If I set VDR up as follows:
Use DiSEqC:no
SLOF (MHz):10750
Low LNB frequency (MHz):   11700
High LNB frequency (MHz):  12500

When I change channels I get:
Sep 25 21:15:18 localhost vdr: [2058] ERROR: frontend 0/0: Invalid argument
Sep 25 21:15:18 localhost kernel: DVB: adapter 0 frontend 0 frequency 
12456000 out of range (95..215)


If I set it to
Use DiSEqC:no
SLOF (MHz):11300
Low LNB frequency (MHz):   11300
High LNB frequency (MHz):  11300

I don't get this error, but get:
Sep 25 21:15:57 localhost vdr: [2058] frontend 0/0 timed out while tuning to 
channel 3, tp 112456
Sep 25 21:17:02 localhost vdr: [2058] frontend 0/0 timed out while tuning to 
channel 3, tp 112456
Sep 25 21:18:07 localhost vdr: [2058] frontend 0/0 timed out while tuning to 
channel 3, tp 112456


I'm using a dm1105 dvb-s card which works under Windows on the same box, but 
szap and VDR do not.  I can scan channels though with:

./scan dvb-s/OptusB1-NZ -l 11300 -x 0

OptusB1-NZ being:
S 12456000 H 2250 AUTO
S 12483000 H 2250 AUTO


Any suggestions?


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Error messages in vdr-1.7.15

[Simon Baxter]

Hi

I'm (now) running vdr-1.7.15, vdr-xine, 2x TT-1500-C cards with Alpha 
mutli-crypt CAMs and pvrinput with a PVR-500 card.


I'm getting a bunch of logs in the console and /var/log/messages, which 
don't appear to be affecting performance.


While replaying recordings I get the followin in the console:
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
PPPAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
AT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
PPAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
AT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
PPPAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
PAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
PPAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205
PPAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
pcr = 1205


I'm also getting this in /var/log/messages:
Sep  8 15:28:24 freddy vdr: [11990] cVideoRepacker: switching to MPEG1/2 
mode
Sep  8 15:28:24 freddy vdr: [11990] cVideoRepacker: operating in MPEG1/2 
mode
Sep  8 15:28:26 freddy vdr: [11990] cVideoRepacker: switching to MPEG1/2 
mode
Sep  8 15:28:26 freddy vdr: [11990] cVideoRepacker: operating in MPEG1/2 
mode
Sep  8 15:28:29 freddy vdr: [11990] cVideoRepacker: switching to MPEG1/2 
mode
Sep  8 15:28:29 freddy vdr: [11990] cVideoRepacker: operating in MPEG1/2 
mode
Sep  8 15:28:30 freddy vdr: [11990] cVideoRepacker: switching to MPEG1/2 
mode
Sep  8 15:28:30 freddy vdr: [11990] cVideoRepacker: operating in MPEG1/2 
mode
Sep  8 15:28:32 freddy vdr: [11990] cVideoRepacker: switching to MPEG1/2 
mode
Sep  8 15:28:32 freddy vdr: [11990] cVideoRepacker: operating in MPEG1/2 
mode

Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (11)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (7)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (14)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (1)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (13)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (5)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (3)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (11)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (14)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (14)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (3)
Sep  8 15:28:32 freddy vdr: [11990] TS continuity error (5)


Doesn't appear to be causing any problems 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr conference streaming

[Simon Baxter]

Hi there,

I am a happy vdr user (vdr 1.7.15 with a DVB-S2 card)

I also happen to be member of an organization that promotes Open Source
(so we should set an example) and we want to stream a conference we are
organizing.

I thought perhaps setting up vdr with a webcam and perhaps vdr-xine or
streamdev would do the job?

The idea is that multiple clients across the country would be able to see
more or less in real time what is going on.

The video does not have to be HD or otherwise impresive (the audio should
be clear)

Is it possible to do this with vdr and could somebody give me a few
pointers and/or a link to a howto?


I suppose you could use the IPTV plugin (which supports uni/multicast) and 
connect to an MCU to receive a conference stream.


You could also use the pvrinput plugin and connect a local camera.

How you'd tie all this into being a nice video conference system is probably 
a bit more of a build.  I've always liked the idea of tying skype and a 
camera into VDR (or XMBC), and using it as a "video-phone in the living 
room".  Never spent any real time doing it though.  Always more things to 
do! 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 orolder OK] [PROGRESS :) ]

[Simon Baxter]

Do these channels have separate VPID and PPID?

channels.conf looks like:
ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=...@4:579:606:1005:182:10:0
TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=...@4:580:606:1006:182:10:0
TV3;T:578000:C0M64:C:6900:1303=2:14...@4:712:606,5601:1003:182:10:0



Does the problem go away if, instead of the above change, you
comment out the line

  (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&

in cReceiver::AddPids()?





Yes - that fixes the problem


ARRGH - spoke too soon.

If I revert to the original device.c and remove that line on receiver.c, I 
get "CAM 2: 'to receive this programme !'" messages:



Sep  6 09:51:52 freddy vdr: [28154] switching to channel 2
Sep  6 09:51:52 freddy vdr: [28154] cTS2PES got 0 TS errors, 1 TS continuity 
errors
Sep  6 09:51:52 freddy vdr: [28154] cTS2PES got 0 TS errors, 2 TS continuity 
errors
Sep  6 09:51:52 freddy vdr: [28487] receiver on device 2 thread started 
(pid=28154, tid=28487)
Sep  6 09:51:52 freddy vdr: [28488] TS buffer on device 2 thread started 
(pid=28154, tid=28488)
Sep  6 09:51:52 freddy vdr: [28486] TS buffer on device 1 thread ended 
(pid=28154, tid=28486)

Sep  6 09:51:52 freddy vdr: [28485] buffer stats: 92120 (4%) used
Sep  6 09:51:52 freddy vdr: [28485] receiver on device 1 thread ended 
(pid=28154, tid=28485)
Sep  6 09:51:56 freddy vdr: [28488] TS buffer on device 2 thread ended 
(pid=28154, tid=28488)

Sep  6 09:51:56 freddy vdr: [28487] buffer stats: 125020 (5%) used
Sep  6 09:51:56 freddy vdr: [28487] receiver on device 2 thread ended 
(pid=28154, tid=28487)

Sep  6 09:51:56 freddy vdr: [28154] switching to channel 2
Sep  6 09:51:56 freddy vdr: [28489] receiver on device 1 thread started 
(pid=28154, tid=28489)
Sep  6 09:51:56 freddy vdr: [28490] TS buffer on device 1 thread started 
(pid=28154, tid=28490)

Sep  6 09:51:56 freddy vdr: [28154] CAM 2: Menu --
Sep  6 09:51:56 freddy vdr: [28154] CAM 2: 'AlphaCrypt'
Sep  6 09:51:56 freddy vdr: [28154] CAM 2: 'You are not entitled'
Sep  6 09:51:56 freddy vdr: [28154] CAM 2: 'to receive this programme !'
Sep  6 09:51:56 freddy vdr: [28154] CAM 2: 'Press OK'
Sep  6 09:51:57 freddy vdr: [28489] cVideoRepacker: switching to MPEG1/2 
mode
Sep  6 09:51:57 freddy vdr: [28489] cVideoRepacker: operating in MPEG1/2 
mode

Sep  6 09:52:09 freddy vdr: [28154] switching to channel 3
Sep  6 09:52:09 freddy vdr: [28495] receiver on device 2 thread started 
(pid=28154, tid=28495)
Sep  6 09:52:09 freddy vdr: [28496] TS buffer on device 2 thread started 
(pid=28154, tid=28496)
Sep  6 09:52:09 freddy vdr: [28490] TS buffer on device 1 thread ended 
(pid=28154, tid=28490)

Sep  6 09:52:09 freddy vdr: [28489] buffer stats: 92120 (4%) used
Sep  6 09:52:09 freddy vdr: [28489] receiver on device 1 thread ended 
(pid=28154, tid=28489)
Sep  6 09:52:13 freddy vdr: [28496] TS buffer on device 2 thread ended 
(pid=28154, tid=28496)

Sep  6 09:52:13 freddy vdr: [28495] buffer stats: 56588 (2%) used
Sep  6 09:52:13 freddy vdr: [28495] receiver on device 2 thread ended 
(pid=28154, tid=28495)

Sep  6 09:52:14 freddy vdr: [28154] switching to channel 3
Sep  6 09:52:14 freddy vdr: [28497] receiver on device 1 thread started 
(pid=28154, tid=28497)

Sep  6 09:52:14 freddy vdr: [28154] CAM 2: Menu --
Sep  6 09:52:14 freddy vdr: [28498] TS buffer on device 1 thread started 
(pid=28154, tid=28498)

Sep  6 09:52:14 freddy vdr: [28154] CAM 2: 'AlphaCrypt'
Sep  6 09:52:14 freddy vdr: [28154] CAM 2: 'You are not entitled'
Sep  6 09:52:14 freddy vdr: [28154] CAM 2: 'to receive this programme !'
Sep  6 09:52:14 freddy vdr: [28154] CAM 2: 'Press OK'
Sep  6 09:52:15 freddy vdr: [28497] cVideoRepacker: switching to MPEG1/2 
mode
Sep  6 09:52:15 freddy vdr: [28497] cVideoRepacker: operating in MPEG1/2 
mode



The device.c hack does not give me these errors. 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]

[Simon Baxter]

On 05.09.2010 21:59, Simon Baxter wrote:

Looks like there are TS packets in your stream that are marked as
"scrambled", but not unscrambled by the CAM.

Do you have any CAM in your system at all?


Yes.  System has 2x TT-1501-C cards and Alphacrypt CAMS


Are the channels where this happens scrambled?

Yes


Do these channels have separate VPID and PPID?

channels.conf looks like:
ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=...@4:579:606:1005:182:10:0
TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=...@4:580:606:1006:182:10:0
TV3;T:578000:C0M64:C:6900:1303=2:14...@4:712:606,5601:1003:182:10:0



Does the problem go away if, instead of the above change, you
comment out the line

  (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&

in cReceiver::AddPids()?





Yes - that fixes the problem

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]

[Simon Baxter]

Looks like there are TS packets in your stream that are marked as
"scrambled", but not unscrambled by the CAM.

Do you have any CAM in your system at all?


Yes.  System has 2x TT-1501-C cards and Alphacrypt CAMS


Are the channels where this happens scrambled?

Yes


Do these channels have separate VPID and PPID?

channels.conf looks like:
ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=...@4:579:606:1005:182:10:0
TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=...@4:580:606:1006:182:10:0
TV3;T:578000:C0M64:C:6900:1303=2:14...@4:712:606,5601:1003:182:10:0



Does the problem go away if, instead of the above change, you
comment out the line

  (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&

in cReceiver::AddPids()?


I can't find that in cReceiver::AddPids()

Do you mean in "bool cReceiver::SetPids(const cChannel *Channel)":
bool cReceiver::SetPids(const cChannel *Channel)
{
 numPids = 0;
 if (Channel) {
channelID = Channel->GetChannelID();
return AddPid(Channel->Vpid()) &&
//(Channel->Ppid() == Channel->Vpid() || 
AddPid(Channel->Ppid())) &&



? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]

[Simon Baxter]

 // Check whether the TS packets are scrambled:

Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug 
printouts.




Thanks Klaus

I've commented out the below section in device.c, and I now get continuous 
video, but some video skips and lots of:
Sep  3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 
mode
Sep  3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2 
mode
Sep  3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 
mode


This cVideoRepacker problem has also been fixed with the attached patch.

So I've managed to get vdr-1.7.15 working just fine now, by disabling this 
scramble check in device.c.  Bit of a dirty hack!!!





Here's what I changed in device.c

void cDevice::Action(void)
{
 if (Running() && OpenDvr()) {
while (Running()) {
  // Read data from the DVR device:
  uchar *b = NULL;
  if (GetTSPacket(b)) {
 if (b) {
int Pid = TsPid(b);
// Check whether the TS packets are scrambled:
bool DetachReceivers = false;
bool DescramblingOk = false;
int CamSlotNumber = 0;
if (startScrambleDetection) {
  cCamSlot *cs = CamSlot();
   CamSlotNumber = cs ? cs->SlotNumber() : 0;
//if (CamSlotNumber) {
//   bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
//   int t = time(NULL) - startScrambleDetection;
//   if (Scrambled) {
//  if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
//  }
//   else if (t > TS_SCRAMBLING_TIME_OK) {
//  DescramblingOk = true;
//  startScrambleDetection = 0;
//  }
//   }
}
// Distribute the packet to all attached receivers:
Lock();


Any ideas?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



vdr-xine-0.9.3-1.7.12.diff
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]

[Simon Baxter]

 // Check whether the TS packets are scrambled:

Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug 
printouts.




Thanks Klaus

I've commented out the below section in device.c, and I now get continuous 
video, but some video skips and lots of:
Sep  3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 
mode
Sep  3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2 
mode
Sep  3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 
mode



Here's what I changed in device.c

void cDevice::Action(void)
{
 if (Running() && OpenDvr()) {
while (Running()) {
  // Read data from the DVR device:
  uchar *b = NULL;
  if (GetTSPacket(b)) {
 if (b) {
int Pid = TsPid(b);
// Check whether the TS packets are scrambled:
bool DetachReceivers = false;
bool DescramblingOk = false;
int CamSlotNumber = 0;
if (startScrambleDetection) {
  cCamSlot *cs = CamSlot();
   CamSlotNumber = cs ? cs->SlotNumber() : 0;
//if (CamSlotNumber) {
//   bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
//   int t = time(NULL) - startScrambleDetection;
//   if (Scrambled) {
//  if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
//  }
//   else if (t > TS_SCRAMBLING_TIME_OK) {
//  DescramblingOk = true;
//  startScrambleDetection = 0;
//  }
//   }
}
// Distribute the packet to all attached receivers:
Lock();


Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] check cam status [writing plugin help needed]

[Simon Baxter]

I'd like to write a plugin which can provide the displayed Setup>CAM 
status via an SVDRP command, and maybe check the CAM menu can be 
accessed.


Had no response on this - guess we have no plugin writers with time on their 
hands to help?


Can I use these functions in ci.h?

 virtual bool Reset(int Slot) = 0;
  ///< Resets the CAM in the given Slot.
  ///< Returns true if the operation was successful.
 virtual eModuleStatus ModuleStatus(int Slot) = 0;
  ///< Returns the status of the CAM in the given Slot.

I just need a very simple svdrp plugin that will 1) check the status of a 
CAM in a given slot via an svdrp command   and 2) reset that cam via another 
svdrp command


What core vdr files do I need to include?  How do I reference or call 
functions within those core files?





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]

[Simon Baxter]

My guess would be that the "DiscontinuityDetected: triggering soft
start"
is generated by the output device, and that causes the transfer mode
to be stoped and restarted. Maybe the output device chokes on something
in the TS stream?



The only place where a 3 second timeout plays a role that also
might cause a channel to become unavailable is in cDevice::Action(),
under

 // Check whether the TS packets are scrambled:

Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug 
printouts.


I've added some markers in device.c as per:
// Check whether the TS packets are scrambled:
bool DetachReceivers = false;
bool DescramblingOk = false;
int CamSlotNumber = 0;
if (startScrambleDetection) {
   cCamSlot *cs = CamSlot();
   CamSlotNumber = cs ? cs->SlotNumber() : 0;
   if (CamSlotNumber) {
  bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
  int t = time(NULL) - startScrambleDetection;
  if (Scrambled) {
   printf("scramble detect ONE");
 if (t > TS_SCRAMBLING_TIMEOUT)
DetachReceivers = true;
 }
  else if (t > TS_SCRAMBLING_TIME_OK) {
   printf("scramble detect TWO");
 DescramblingOk = true;
 startScrambleDetection = 0;
 }
  }
   }


Am getting lots of "scramble detect ONE" messages as per above...

Now what? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]

[Simon Baxter]

The only place where a 3 second timeout plays a role that also
might cause a channel to become unavailable is in cDevice::Action(),
under

 // Check whether the TS packets are scrambled:

Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug 
printouts.


Klaus


How do I do this?
Is it as simple as :
-  startScrambleDetection = 0;
+  startScrambleDetection = 1;

or comment out:
// if (startScrambleDetection) {
//cCamSlot *cs = CamSlot();
//CamSlotNumber = cs ? cs->SlotNumber() : 0;
//if (CamSlotNumber) {
//   bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
//   int t = time(NULL) - startScrambleDetection;
//   if (Scrambled) {
//  if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
//  }
//   else if (t > TS_SCRAMBLING_TIME_OK) {
//  DescramblingOk = true;
//  startScrambleDetection = 0;
//  }
//   }
//}

or something else? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]

[Simon Baxter]

Am 29.08.2010 15:06, schrieb Klaus Schmidinger:


DiscontinuityDetected: triggering soft start


You may want to find out where this message comes from (it certainly
doesn't come from the core VDR).


This is just an implementation detail of vdr-xine.


Why am I getting a "SetPlayMode: 0"  and  "receiver on device 2 thread
ended (pid=16557, tid=16633)"  for no reason??


When a receiver is detached from a device, the play mode is set to pmNone
(which is 0).

My guess would be that the "DiscontinuityDetected: triggering soft start"
is generated by the output device, and that causes the transfer mode
to be stoped and restarted. Maybe the output device chokes on something
in the TS stream?


I doubt that vdr-xine does anything which would cause transfer
mode to be stopped and restarted.


I have the same problem (transfer mode stopping) with plain VDR (no plugins) 
and a FF card.

i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12)

Happy to do any captures etc - any suggestions?? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]

[Simon Baxter]

Summary of problem:
vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before screen goes 
blank
system has TT-1501 abd TT-2300 cards - makes no difference whether xine 
plugin is running or not
same problem running through TT-2300 FF card vdr-1.7.<=11 works fine. 
vdr-1.7.>=12 shows the problem


I'm still no futher with this, can anyone please help?

I turned on ci.c debugging to see what happens differently between 
vdr-1.7.11 and vdr-1.7.15.


1.7.11 -> switch to channel 1 and on the console I see:
SetPlayMode: 0
Slot 1: ==> Ca Pmt (3) 5 1
1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EB 01 00 07 01 09 
04 06 06 E4 52

Slot 1: ==> Ca Pmt (3) 4 1
1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 
04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00

SetPlayMode: 1

in messages, I see:
Aug 28 12:53:15 freddy vdr: [17052] switching to channel 1
Aug 28 12:53:15 freddy vdr: [17104] TS buffer on device 1 thread ended 
(pid=17052, tid=17104)

Aug 28 12:53:15 freddy vdr: [17103] buffer stats: 80840 (3%) used
Aug 28 12:53:15 freddy vdr: [17103] receiver on device 1 thread ended 
(pid=17052, tid=17103)
Aug 28 12:53:15 freddy vdr: [17105] receiver on device 1 thread started 
(pid=17052, tid=17105)
Aug 28 12:53:15 freddy vdr: [17106] TS buffer on device 1 thread started 
(pid=17052, tid=17106)
Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: switching to MPEG1/2 
mode
Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: operating in MPEG1/2 
mode


i.e.  ALL OK

In vdr-1.7.15 on the same box, I see:
SetPlayMode: 0
Slot 2: ==> Ca Pmt (3) 5 1
2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 
04 06 06 E4 54

Slot 2: ==> Ca Pmt (3) 4 1
2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 
04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00

SetPlayMode: 1
[v]
DiscontinuityDetected: triggering soft start
[vAVM]buffered 7.1 frames (v:12.2, a:7.1)
SetPlayMode: 0
Slot 2: ==> Ca Pmt (3) 5 1
2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 
04 06 06 E4 54

Slot 1: ==> Ca Pmt (3) 4 1
1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 
04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00

SetPlayMode: 1
[v]
DiscontinuityDetected: triggering soft start
[vAVM]buffered 7.3 frames (v:13.0, a:7.3)
SetPlayMode: 0
Slot 1: ==> Ca Pmt (3) 5 1
1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 
04 06 06 E4 54

Slot 2: ==> Ca Pmt (3) 4 1
2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 
04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00

SetPlayMode: 1
[v]

and in messages:
Aug 28 12:50:10 freddy vdr: [16633] receiver on device 2 thread started 
(pid=16557, tid=16633)
Aug 28 12:50:10 freddy vdr: [16634] TS buffer on device 2 thread started 
(pid=16557, tid=16634)
Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: switching to MPEG1/2 
mode
Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: operating in MPEG1/2 
mode
Aug 28 12:50:14 freddy vdr: [16634] TS buffer on device 2 thread ended 
(pid=16557, tid=16634)

Aug 28 12:50:14 freddy vdr: [16633] buffer stats: 192700 (9%) used
Aug 28 12:50:14 freddy vdr: [16633] receiver on device 2 thread ended 
(pid=16557, tid=16633)

Aug 28 12:50:21 freddy vdr: [16557] switching to channel 1
Aug 28 12:50:21 freddy vdr: [16635] receiver on device 1 thread started 
(pid=16557, tid=16635)
Aug 28 12:50:21 freddy vdr: [16636] TS buffer on device 1 thread started 
(pid=16557, tid=16636)
Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: switching to MPEG1/2 
mode
Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: operating in MPEG1/2 
mode
Aug 28 12:50:25 freddy vdr: [16636] TS buffer on device 1 thread ended 
(pid=16557, tid=16636)

Aug 28 12:50:25 freddy vdr: [16635] buffer stats: 173712 (8%) used
Aug 28 12:50:25 freddy vdr: [16635] receiver on device 1 thread ended 
(pid=16557, tid=16635)


i.e. I get 3 second "bursts" of live TV, but blank screen as the receiver 
threads restart


Why am I getting a "SetPlayMode: 0"  and  "receiver on device 2 thread ended 
(pid=16557, tid=16633)"  for no reason??




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] check cam status [writing plugin help needed]

[Simon Baxter]

I'd like to write a plugin which can provide the displayed Setup>CAM 
status via an SVDRP command, and maybe check the CAM menu can be accessed.


As a beginner to such things, can someone help?


I basically want to implement bits of menu.c (the CAM status and menu 
accessing parts) via SVDRP.

Can someone please help?


If I pull some of the following from menu.c I think this should give me 
what I want:


Get list of availablecams:
void cMenuCam::GenerateTitle(const char *s)
{
 SetTitle(cString::sprintf("CAM %d - %s", camSlot->SlotNumber(), (s && *s) 
? s : camSlot->GetCamName()));

}

Get the CAM status (being Ready, Present, -, or "Alphacrypt" etc:
bool cMenuSetupCAMItem::Changed(void)
{
 char buffer[32];
 const char *CamName = camSlot->GetCamName();
 if (!CamName) {
switch (camSlot->ModuleStatus()) {
  case msReset:   CamName = tr("CAM reset"); break;
  case msPresent: CamName = tr("CAM present"); break;
  case msReady:   CamName = tr("CAM ready"); break;
  default:CamName = "-"; break;
  }
}
 snprintf(buffer, sizeof(buffer), " %d %s", camSlot->SlotNumber(), 
CamName);

 if (strcmp(buffer, Text()) != 0) {
SetText(buffer);
return true;
}
 return false;
}



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] check cam status [writing plugin help needed]

[Simon Baxter]

Ideally, I'd like a way to "ask vdr" the status of the CAM from a script. 
I know this is available on the OSD by going into the "SETUP > CAM" menu 
where the CAM is displayed as "CAM Ready", "CAM Present" or "Alhpacrypt" 
but I need to do this outside the OSD.


Anyone have any ideas how to do this?


I'd like to write a plugin which can provide the displayed Setup>CAM status 
via an SVDRP command, and maybe check the CAM menu can be accessed.


As a beginner to such things, can someone help?

I want to use svdrpdemo as the starting point.  What else do I need to 
include in this?

#include "menu.h"
#include "svdrpservice.h" (from femon plugin)
??

If I pull some of the following from menu.c I think this should give me what 
I want:


Get list of availablecams:
void cMenuCam::GenerateTitle(const char *s)
{
 SetTitle(cString::sprintf("CAM %d - %s", camSlot->SlotNumber(), (s && *s) 
? s : camSlot->GetCamName()));

}

Get the CAM status (being Ready, Present, -, or "Alphacrypt" etc:
bool cMenuSetupCAMItem::Changed(void)
{
 char buffer[32];
 const char *CamName = camSlot->GetCamName();
 if (!CamName) {
switch (camSlot->ModuleStatus()) {
  case msReset:   CamName = tr("CAM reset"); break;
  case msPresent: CamName = tr("CAM present"); break;
  case msReady:   CamName = tr("CAM ready"); break;
  default:CamName = "-"; break;
  }
}
 snprintf(buffer, sizeof(buffer), " %d %s", camSlot->SlotNumber(), 
CamName);

 if (strcmp(buffer, Text()) != 0) {
SetText(buffer);
return true;
}
 return false;
}


Can anyone help me on this? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] check cam status

[Simon Baxter]

Ideally, I'd like a way to "ask vdr" the status of the CAM from a script. 
I know this is available on the OSD by going into the "SETUP > CAM" menu 
where the CAM is displayed as "CAM Ready", "CAM Present" or "Alhpacrypt" 
but I need to do this outside the OSD.


Anyone have any ideas how to do this?



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

Hi,
Ok, I use xineliboutput and vdr-xione here with no errors under
vdr-1.7.15.
If you have then check you xine-lib installation and the used
videodriver.
Sorry no other idea.
Br.
halim


I'm pretty sure it's not xine-lib related.

I also have a FF card (TT-2300) which I run with no plugins - and get the 
same problem.


Summary of problem:
- vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before 
"SetPlayMode: 0", blank screen, sequence of "channel not available", then a 
few seconds of TV (repeats)

- system has TT-1501 abd TT-2300 cards
- usage of vdr-xine-0.9.3 or not makes no difference.  i.e. TT-2300 FF card 
has same problem with no vdr-xine loaded.



- vdr-1.7.11 or older does not show this fault.  i.e.  vdr-1.7.9 and 
vdr-1.7.10 work 100% perfect.



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

Hi,
Have you updated the firmware of the tt 2300?
Check the mailinglist archives for instructions.
You need also the newest drivers.
BR.
Halim


Thanks will try on the TT-2300, but I'm getting the same problem with the 
TT-1501 cards - which don't need a separate firmware load.



?? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

If I run vdr-1.6.0 it works fine, it's just vdr-1.7.15 that doesn't.  So 
I'm not thinking this is a system problem.


have made a bit of a breakthrough - I've found any vdr version up to and 
including vdr-1.7.11 works fine.  From vdr-1.7.12 I get the 3 seconds of 
live TV problem.


Tested vdr-1.7.0,1,2,3,4,5,6,7,8,9,10,11,12,14,15.

This is in the HISTORY for vdr-1.7.12:
- The PCR pid in generated PMTs is now set to the channel's PCR pid again.
- Fixed determining the frame duration on channels where the PTS deltas 
jitter by

 +/-1 around 3600.
- The PCR pid is now recorded for channels where this is different from the 
video
 PID. To facilitate this, the interfaces of cTransfer, cTransferControl, 
cRecorder
 and cReceiver have been modified, so that the PIDs are no longer given in 
separate
 parameters, but rather the whole channel is handed down for processing. 
The old
 constructor of cReceiver is still available, but it is recommended to 
plugin authors

 that they switch to the new interface as soon as possible.
 When replaying such a recording, the PCR packets are sent to PlayTsVideo()

Could it be something to do with this?

Summary of problem:
- vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before 
"SetPlayMode: 0", blank screen, sequence of "channel not available", then a 
few seconds of TV (repeats)

- system has TT-1501 abd TT-2300 cards
- usage of vdr-xine-0.9.3 or not makes no difference.  i.e. TT-2300 FF card 
has same problem with no vdr-xine loaded.

- any vdr version 1.7.11 or older does not show this fault.

any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

If I run vdr-1.6.0 it works fine, it's just vdr-1.7.15 that doesn't.  So I'm 
not thinking this is a system problem.



Just an off the wall guess, buffer problem? Not that much ram needed, but 
how much does the system have?


On 7/31/2010 12:29 AM, Simon Baxter wrote:

On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter 
wrote:

This is all very fascinating, but can anyone offer a suggestion to how
I can
debug my 3 seconds of live TV problem?


When I switch to any live SD channel, I only get 3 seconds of
audio/video
and then then "channel not available". A few seconds later the picture
comes back, for another 3 seconds, then unavailable.

Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread
started
(pid=2499, tid=2532)
Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread
started
(pid=2499, tid=2533)
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to
MPEG1/2
mode
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in
MPEG1/2
mode
Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread
ended
(pid=2499, tid=2533)
Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used
Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread 
ended

(pid=2499, tid=2532)
Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!



Not enough information. Assuming channel 1 is a real channel for you,
check your xine log and cam log also. Usually "Channel not available"
seems to mean the cam can't decrypt the channel or the tuner is in use
already (such as a timer is active on another channel).


This is a test box with no timers or other front ends, so the tuner
isn't in use anywhere.
Above result happens no matter which channel I change to - 3 seconds of
live TV then thread ends.

I've also tested using a FF card (so no xine front end) and still only
getting 3 seconds of video.

Using vdr-xine, XINE logs, all I'm getting is:
vdr: osdflush: n: 3, 32.6, timeout: 0, result: 0
vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0
vdr: osdflush: n: 3, 33.6, timeout: 0, result: 0
vdr: osdflush: n: 3, 30.3, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0


CAM logs as follows:
SetPlayMode: 1
Slot 2: ==> Date Time (4)
2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 24 57 00 02
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 00
. . . . . . . . @ . A . . . .
Slot 2: open session 00400041
Slot 2: new MMI (session id 5)
2: --> 01 01 A0 0A 01 92 07 00 00 40 00 41 00 05
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 82 00 0B 01 90 02 00 05 9F 88 01 02 01 01 80 02 01 00
. . . . . . . . . . . . . . . . . . . . .
Slot 2: <== Display Control (5)
Slot 2: ==> Display Reply (5)
2: --> 01 01 A0 0B 01 90 02 00 05 9F 88 02 02 01 01
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 82 00 61 01 90 02 00 05 9F 88 0C 58 02 9F 88 03 0B 97 41
6C 70 68 61 43 72 79 70 74 9F 88 03 01 20 9F 88 03 08 50 72 65 73 73 20
4F 4B 9F 88 03 14 59 6F 75 20 61 72 65 20 6E 6F 74 20 65 6E 74 69 74 6C
65 64 9F 88 03 1B 74 6F 20 72 65 63 65 69 76 65 20 74 68 69 73 20 70 72
6F 67 72 61 6D 6D 65 20 21 80 02 01 00
. . . . . a . . . . . . . . X . . . . . . A l p h a C r y p t . . . . .
. . . P r e s s O K . . . . Y o u a r e n o t e n t i t l e d . . . . t
o r e c e i v e t h i s p r o g r a m m e ! . . . .
Slot 2: <== Menu Last (5)
Slot 2: <== Text Last (5) 'AlphaCrypt'
Slot 2: <== Text Last (5) ''
Slot 2: <== Text Last (5) 'Press OK'
Slot 2: <== Text Last (5) 'You are not entitled'
Slot 2: <== Text Last (5) 'to receive this programme !'
SetPlayMode: 0
Slot 2: ==> Ca Pmt (3) 5 1
2: --> 01 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EE 01 00 07 01 09 04
06 06 E4 51
frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00)
Slot 2: ==> Date Time (4)
2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 25 03 00 02
Slot 2: ==> Close MMI (5)
2: --> 01 01 A0 09 01 90 02 00 05 9F 88 00 00
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 05 01 95 02 00 05 80 02 01 00
. . . . . . . . . . . . .
Slot 2: close session 5
2: --> 01 01 A0 06 01 96 03 00 00 05


___
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




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter  
wrote:
This is all very fascinating, but can anyone offer a suggestion to how I 
can

debug my 3 seconds of live TV problem?

When I switch to any live SD channel, I only get 3 seconds of 
audio/video

and then then "channel not available". A few seconds later the picture
comes back, for another 3 seconds, then unavailable.

Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread 
started

(pid=2499, tid=2532)
Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread
started
(pid=2499, tid=2533)
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to
MPEG1/2
mode
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in
MPEG1/2
mode
Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended
(pid=2499, tid=2533)
Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used
Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended
(pid=2499, tid=2532)
Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!



Not enough information.  Assuming channel 1 is a real channel for you,
check your xine log and cam log also.  Usually "Channel not available"
seems to mean the cam can't decrypt the channel or the tuner is in use
already (such as a timer is active on another channel).


This is a test box with no timers or other front ends, so the tuner isn't in 
use anywhere.
Above result happens no matter which channel I change to - 3 seconds of live 
TV then thread ends.


I've also tested using a FF card (so no xine front end) and still only 
getting 3 seconds of video.


Using vdr-xine, XINE logs, all I'm getting is:
vdr: osdflush: n: 3, 32.6, timeout: 0, result: 0
vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0
vdr: osdflush: n: 3, 33.6, timeout: 0, result: 0
vdr: osdflush: n: 3, 30.3, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0


CAM logs as follows:
SetPlayMode: 1
Slot 2: ==> Date Time (4)
2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 24 57 00 02
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 00
   .  .  .  .  .  .  .  .  @  .  A  .  .  .  .
Slot 2: open session 00400041
Slot 2: new MMI (session id 5)
2: --> 01 01 A0 0A 01 92 07 00 00 40 00 41 00 05
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 82 00 0B 01 90 02 00 05 9F 88 01 02 01 01 80 02 01 00
   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Slot 2: <== Display Control (5)
Slot 2: ==> Display Reply (5)
2: --> 01 01 A0 0B 01 90 02 00 05 9F 88 02 02 01 01
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 82 00 61 01 90 02 00 05 9F 88 0C 58 02 9F 88 03 0B 97 
41 6C 70 68 61 43 72 79 70 74 9F 88 03 01 20 9F 88 03 08 50 72 65 73 73 20 
4F 4B 9F 88 03 14 59 6F 75 20 61 72 65 20 6E 6F 74 20 65 6E 74 69 74 6C 65 
64 9F 88 03 1B 74 6F 20 72 65 63 65 69 76 65 20 74 68 69 73 20 70 72 6F 67 
72 61 6D 6D 65 20 21 80 02 01 00
   .  .  .  .  .  a  .  .  .  .  .  .  .  .  X  .  .  .  .  .  .  A 
l  p  h  a  C  r  y  p  t  .  .  .  . .  .  .  .  P  r  e  s  s O  K 
.  .  .  .  Y  o  u a  r  e n  o  t e  n  t  i  t  l  e  d  .  . 
.  .  t  o r  e  c  e  i  v  e t  h  i  s p  r  o  g  r  a  m  m 
e !  .  .  .  .

Slot 2: <== Menu Last (5)
Slot 2: <== Text Last (5) 'AlphaCrypt'
Slot 2: <== Text Last (5) ''
Slot 2: <== Text Last (5) 'Press OK'
Slot 2: <== Text Last (5) 'You are not entitled'
Slot 2: <== Text Last (5) 'to receive this programme !'
SetPlayMode: 0
Slot 2: ==> Ca Pmt (3) 5 1
2: --> 01 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EE 01 00 07 01 09 
04 06 06 E4 51

frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00)
Slot 2: ==> Date Time (4)
2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 25 03 00 02
Slot 2: ==> Close MMI (5)
2: --> 01 01 A0 09 01 90 02 00 05 9F 88 00 00
Slot 2: receive data 1/1
2: --> 01 01 81 01 01
2: <-- 01 01 A0 05 01 95 02 00 05 80 02 01 00
   .  .  .  .  .  .  .  .  .  .  .  .  .
Slot 2: close session 5
2: --> 01 01 A0 06 01 96 03 00 00 05


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

On Thu, Jul 29, 2010 at 12:55 PM, Morfsta  wrote:

Isn't it about time that VDR had a native out of the box plugin for
X11 output with H264 acceleration? There's so many problems with
having xine or xinelibout plugins developed by 3rd parties and relying
on syncing up with xine etc...



This is all very fascinating, but can anyone offer a suggestion to how I can 
debug my 3 seconds of live TV problem?



When I switch to any live SD channel, I only get 3 seconds of audio/video
and then then "channel not available".  A few seconds later the picture
comes back, for another 3 seconds, then unavailable.

Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started
(pid=2499, tid=2532)
Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread
started
(pid=2499, tid=2533)
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to
MPEG1/2
mode
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in
MPEG1/2
mode
Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended
(pid=2499, tid=2533)
Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used
Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended
(pid=2499, tid=2532)
Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

Any ideas or suggestions from anyone?




When I switch to any live SD channel, I only get 3 seconds of audio/video
and then then "channel not available".  A few seconds later the picture
comes back, for another 3 seconds, then unavailable.

Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started
(pid=2499, tid=2532)
Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread 
started

(pid=2499, tid=2533)
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to 
MPEG1/2

mode
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in 
MPEG1/2

mode
Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended
(pid=2499, tid=2533)
Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used
Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended
(pid=2499, tid=2532)
Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1
Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started
(pid=2499, tid=2535)
Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread 
started

(pid=2499, tid=2536)
Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to 
MPEG1/2

mode
Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in 
MPEG1/2

mode
Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended
(pid=2499, tid=2536)
Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used
Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended
(pid=2499, tid=2535)
Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1
Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!

The same setup works fine under vdr-1.6.0.


Incidentally, I tried the attached patch for vdr-xine and the VPID issue,
but it had no effect.

Also tried recording a channel via skincurses without xine-ui attached, 
but

still get the above errors and corresponding console messages:
SetPlayMode: 1
SetPlayMode: 0

Is there more debugging I can turn on?  Why am I getting the "receiver on
device 1 thread ended" ?



Thanks
Simon








___
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] vdr-1.7.15 problem with TV

[Simon Baxter]

When I switch to any live SD channel, I only get 3 seconds of audio/video 
and then then "channel not available".  A few seconds later the picture 
comes back, for another 3 seconds, then unavailable.


Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started 
(pid=2499, tid=2532)
Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started 
(pid=2499, tid=2533)
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 
mode
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 
mode
Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended 
(pid=2499, tid=2533)

Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used
Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended 
(pid=2499, tid=2532)

Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1
Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started 
(pid=2499, tid=2535)
Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started 
(pid=2499, tid=2536)
Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 
mode
Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 
mode
Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended 
(pid=2499, tid=2536)

Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used
Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended 
(pid=2499, tid=2535)

Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1
Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!

The same setup works fine under vdr-1.6.0.


Incidentally, I tried the attached patch for vdr-xine and the VPID issue, 
but it had no effect.


Also tried recording a channel via skincurses without xine-ui attached, but 
still get the above errors and corresponding console messages:

SetPlayMode: 1
SetPlayMode: 0

Is there more debugging I can turn on?  Why am I getting the "receiver on 
device 1 thread ended" ?




Thanks
Simon 


vdr-xine-0.9.3-1.7.12.diff
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] vdr-1.7.15 problem with TV

[Simon Baxter]

Hi

I've just installed vdr-1.7.15 on my development box which has a single 
TT-2300 DVB card and CAM installed.  I'm using vdr-xine as my front end.


When I switch to any live SD channel, I only get 3 seconds of audio/video 
and then then "channel not available".  A few seconds later the picture 
comes back, for another 3 seconds, then unavailable.


logs look like this:

Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started 
(pid=2499, tid=2532)
Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started 
(pid=2499, tid=2533)
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 
mode
Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 
mode
Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended 
(pid=2499, tid=2533)

Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used
Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended 
(pid=2499, tid=2532)

Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1
Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1
Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started 
(pid=2499, tid=2535)
Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started 
(pid=2499, tid=2536)
Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 
mode
Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 
mode
Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended 
(pid=2499, tid=2536)

Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used
Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended 
(pid=2499, tid=2535)

Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1
Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!

The same setup works fine under vdr-1.6.0.

Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] radio-0.2.5 compile error

[Simon Baxter]

Hi,

it has been fixed in vdr-radio version 0.9x:
http://egal-vdr.de/plugins/in_progress/vdr-radio-0.9.0pre.tgz

or attached patch, thx to z...@vdr-portal.




Thanks!

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] radio-0.2.5 compile error

[Simon Baxter]

Hi

Under vdr-1.7.15 I'm getting this compile error:
[r...@localhost radio]# make
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE 
-DPLUGIN_NAME_I18N='"radio"' -I../../../include -I/include radioepg.c
radioepg.c: In function 'int epg_premiere(const char*, const char*, time_t, 
time_t)':

radioepg.c:26: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:31: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:42: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:55: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:60: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:72: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:90: error: invalid conversion from 'const char*' to 'char*'
radioepg.c: In function 'int epg_kdg(const char*, time_t, time_t)':
radioepg.c:157: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:168: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:179: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:190: error: invalid conversion from 'const char*' to 'char*'
radioepg.c: In function 'int epg_unitymedia(const char*, const char*, 
time_t, time_t)':

radioepg.c:257: error: invalid conversion from 'const char*' to 'char*'
radioepg.c:260: error: invalid conversion from 'const char*' to 'char*'
make: *** [radioepg.o] Error 1

Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] epgsearch 0.9.24 conflict check problem??

[Simon Baxter]

Have just upgraded vdr-1.6.0 to epgsearch plugin version 0.9.25.beta16 
because of an increasing problem with 0.9.24 and timer conflicts.


0.9.24 was reporting timer conflicts where none existed - 0.9.25.beta16 
seems to have resolved this problem!



Happy days :) 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] OSD not working

[Simon Baxter]

Try testing it with skincurses plugin, from a console.  Start vdr-sxfe, then 
switch OSD from Skincurses.



- Original Message - 
From: "VDR User" 

To: "VDR Mailing List" 
Sent: Monday, May 31, 2010 12:16 PM
Subject: Re: [vdr] OSD not working



On Sun, May 30, 2010 at 4:22 PM, James Courtier-Dutton
 wrote:

I am using vdr 1.7.14.
I cannot see an OSD menu when using the vdr-sxfe client.
Am I missing a plugin?
If so, which one.


VDR comes with an own OSD built-in.  Maybe your settings in setup.conf
need to be fixed(?).

___
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] check cam status

[Simon Baxter]

I'm needing to reset my CAM periodically, and in order to do this I need 
to check it's status from outside VDR.


I've been doing the following, which is not ideal:
if [ $((`tail -n $LINES /var/log/messages | grep 'vdr:' | grep 'ERROR' | 
grep 'CI' | wc -l`)) = 0 ]

to test for:
"May 22 00:49:45 freddy vdr: [9061] ERROR: can't write to CI adapter on 
device 1: Input/output error "  messages



and then:
"while [ $((`tail -n $LINES /var/log/messages | grep 'dvb_ca adapter 1: 
DVB CAM detected and initialised successfully' | wc -l`)) = 0 ]"  to test 
it's recovered



Does anyone have any better suggestions???



Ideally, I'd like a way to "ask vdr" the status of the CAM from a script.  I 
know this is available on the OSD by going into the "SETUP > CAM" menu where 
the CAM is displayed as "CAM Ready", "CAM Present" or "Alhpacrypt"   but I 
need to do this outside the OSD.



Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] check cam status

[Simon Baxter]

Hello

I'm needing to reset my CAM periodically, and in order to do this I need to 
check it's status from outside VDR.


I've been doing the following, which is not ideal:
if [ $((`tail -n $LINES /var/log/messages | grep 'vdr:' | grep 'ERROR' | 
grep 'CI' | wc -l`)) = 0 ]

to test for:
"May 22 00:49:45 freddy vdr: [9061] ERROR: can't write to CI adapter on 
device 1: Input/output error "  messages



and then:
"while [ $((`tail -n $LINES /var/log/messages | grep 'dvb_ca adapter 1: DVB 
CAM detected and initialised successfully' | wc -l`)) = 0 ]"  to test it's 
recovered



Does anyone have any better suggestions???




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] intermittant "Channel Not Available" vdr-1.6.0

[Simon Baxter]

Hi

I'm running 2x DVB-C + CI/CAMS and getting intermittant channel not 
available messages:


I'm running 2.6.27.41-170.2.117.fc10.x86_64 with a recent v4l-dvb.  In the 
past when I've had these problems, I've been able to fix by adding some

msleep(1);
statements in v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c

But it's still doing it.

If I switch back and forth between channels and devices (using femon) I can 
get the channel to work on both cards/CAMs.


Any ideas?




Apr 27 22:06:06 freddy vdr: [11775] switching to channel 1
Apr 27 22:06:06 freddy vdr: [11775] buffer stats: 81216 (3%) used
Apr 27 22:06:06 freddy vdr: [11775] info: Channel not available!
Apr 27 22:06:08 freddy vdr: [11775] CAM 2: Menu --
Apr 27 22:06:08 freddy vdr: [11775] CAM 2: 'AlphaCrypt'
Apr 27 22:06:08 freddy vdr: [11775] CAM 2: 'You are not entitled'
Apr 27 22:06:08 freddy vdr: [11775] CAM 2: 'to receive this programme !'
Apr 27 22:06:08 freddy vdr: [11775] CAM 2: 'Press OK'
Apr 27 22:06:17 freddy vdr: [11775] switching to channel 1
Apr 27 22:06:17 freddy vdr: [11775] info: Channel not available!
Apr 27 22:06:56 freddy vdr: [11775] closing SVDRP connection
Apr 27 22:07:03 freddy vdr: [11775] switching to channel 1
Apr 27 22:07:03 freddy vdr: [15407] transfer thread started (pid=11775, 
tid=15407)
Apr 27 22:07:03 freddy vdr: [15408] receiver on device 1 thread started 
(pid=11775, tid=15408)
Apr 27 22:07:03 freddy vdr: [15409] TS buffer on device 1 thread started 
(pid=11775, tid=15409)

Apr 27 22:07:06 freddy vdr: [11775] switching to channel 1
Apr 27 22:07:06 freddy vdr: [15407] transfer thread ended (pid=11775, 
tid=15407)

Apr 27 22:07:06 freddy vdr: [11775] buffer stats: 77268 (3%) used
Apr 27 22:07:06 freddy vdr: [15410] transfer thread started (pid=11775, 
tid=15410)
Apr 27 22:07:06 freddy vdr: [15409] TS buffer on device 1 thread ended 
(pid=11775, tid=15409)

Apr 27 22:07:06 freddy vdr: [15408] buffer stats: 76892 (3%) used
Apr 27 22:07:06 freddy vdr: [15408] receiver on device 1 thread ended 
(pid=11775, tid=15408)
Apr 27 22:07:06 freddy vdr: [15411] receiver on device 1 thread started 
(pid=11775, tid=15411)
Apr 27 22:07:06 freddy vdr: [15412] TS buffer on device 1 thread started 
(pid=11775, tid=15412)

Apr 27 22:07:07 freddy vdr: [15410] setting audio track to 1 (0)



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] PVRINPUT plugin and "black/cinema bars"

[Simon Baxter]

If you want to limit the plugin to using only the hardware then I
agree.  However, if you want to provide capabilities beyond what the
hardware is capable of then software is the only other place to do it.
This is perfectly fine, although it probably means the user wasted
his money on a hardware decoder if he's just going to do software
decoding anyways.  It doesn't hurt to put more consideration into what
you want/need before pouring money into hardware.  I know guys that
threw a lot of money at hardware decoders only to replace them with
cheap vdpau-capable video cards.  To each his own I suppose. :)


I think Martin's talking about the PVR-500 encoding aspect, not 
hardware-vs-software decoders.


I have no qualms about recoding - my production box is dual core 64-bit and 
sits mostly idle anyway :) 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] PVRINPUT plugin and "black/cinema bars"

[Simon Baxter]

You _could_ write some functions to detect and remove letterboxing,
though I don't know anyone motivated enough to actually do it.


The main goal of the pvrinput-plugin is to use the hardware encoder.I 
think it

is a bad idea to do software-based on-the-fly-recoding.

Simon, which output device do you use? Maybe the xine- or 
xineliboutput-Plugin

can do the needed zoom for you. (?)



I'm using vdr-xine, but as I have 2x DVB-C cards also there's only about 5 
channels which I receive via the PVR-500.  I could change the aspect in 
xine, but it would change it for ALL channels wouldn't it?


Is there a flag I can send xine to crop only _some_ channels?

I could also enable a remote key to switch aspect in xine, but I'm currently 
using vdr's lirc interface so would need to switch to xine's lirc (which can 
send lirc messages to vdr).  Don't really want to do this - if possible.


Or is there another way around this? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] PVRINPUT plugin and "black/cinema bars"

[Simon Baxter]

you should upgrade to our new pvrinput version:
http://projects.vdr-developer.org/attachments/download/288/vdr-
pvrinput-2010-04-14.tgz
see 
http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/HISTORY


I am pretty sure that your TV station broadcasts analogue TV not 
anamorphic,

which means it "delivers" the black bars to prevent the aspect  ratio of a
16:9 content.


You're right - have checked on an analog input to the TV directly and the 
bars are there, being sent by the service provider.  Damn!



Using the full screen for 16:9 content would result in "egg heads".  We 
call
this anamorphic. A 16:9 TV would stretch this; a 4:3 TV screen would need 
to

scale it down (generating the needed bars).
At least in Germany analogue broadcastings are never anamorphic.
I gues you are using the extern inputs to supply video from a digital
receiver? Then it could be anamorphic of course. You would need to tell 
your

digibox that you have a 16:9 TV.


Nope, am using the tuner on-board in the PVR-500.

Unfortunately there is no way to detect the incoming signal (Tuner or 
extern).

Therefore it is not possible to automatically choose the right setting.


Any ideas how to remove these?
The driver does not support clipping/cropping. We will always encode the 
whole

capture size. If there is already a bar, it will also be in the encoded
stream. You could try to use the zoom mode of your TV.


This doesn't work either, as the "PC input" setting on my Sony Bravia 
doesn't allow zooming.


I guess I'm stuck with the bars, unless someone can suggest how to crop in 
VDR or on the ivtv driver?




Plugin setup is as follows:
pvrinput.BackupHack = 0
pvrinput.BackupInterval = 30
pvrinput.EnableDigibox = 1
pvrinput.FastChannelChange = 1
pvrinput.RedRemoteDevice = /dev/ledxmit


These setup items have never been in any pvrinput version, so I gues you 
made

patches. Could you provide them to me?


I'm not actually using these settings now, but was when I was using the 
analog output from my cable STB and needed PVRINPUT to change the channel 
using an IR transmitter.


Sorry, but I'm going to have to go through some backups to get this hack - 
will get back to you



Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] PVRINPUT plugin and "black/cinema bars"

[Simon Baxter]

Hi Everyone

My machine has (among others) a PVR-500 dual-channel analog card and I'm 
running vdr-1.6.0 with pvrinput-2008-07-05.


Doesn't matter which aspect ratio I choose, every channel under the PVR-500 
displays with black (cinema) bars on the top and bottom of the image.


Plugin setup is as follows:

pvrinput.AspectRatio = 2
pvrinput.AudioBitrate = 10
pvrinput.AudioSampling = 1
pvrinput.AudioVolume = 58982
pvrinput.AudioVolumeFM = 65535
pvrinput.AudioVolumeTV = 62258
pvrinput.BackupHack = 0
pvrinput.BackupInterval = 30
pvrinput.BitrateMode = 0
pvrinput.Brightness = 128
pvrinput.Contrast = 64
pvrinput.EnableDigibox = 1
pvrinput.FastChannelChange = 1
pvrinput.FilterChromaMedianBottom = 0
pvrinput.FilterChromaMedianTop = 255
pvrinput.FilterChromaSpatialType = 0
pvrinput.FilterLumaMedianBottom = 0
pvrinput.FilterLumaMedianTop = 255
pvrinput.FilterLumaSpatialType = 0
pvrinput.FilterMedianType = 0
pvrinput.FilterSpatial = 0
pvrinput.FilterSpatialMode = 1
pvrinput.FilterTemporal = 0
pvrinput.FilterTemporalMode = 0
pvrinput.HideMainMenuEntry = 1
pvrinput.Hue = 0
pvrinput.LogLevel = 3
pvrinput.Pulldown = 0
pvrinput.Pvrusb2StopOnChange = 0
pvrinput.RedRemoteDevice = /dev/ledxmit
pvrinput.Saturation = 64
pvrinput.SliceVBI = 0
pvrinput.TunerAudioMode = 4
pvrinput.UseDeviceType = 1
pvrinput.VideoBitrate = 6000
pvrinput.VideoBitrateFM = 1500
pvrinput.VideoBitrateTV = 6000


Also attached (if it comes through?) is a screenshot.

Any ideas how to remove these?

Thanks

Simon 
<>___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TS Play Plugin - breaks streamdev and radio plugins

[Simon Baxter]

Then please check VDR's recording.h. The missing IsPesRecording member
function and the parameter type mismatch of cIndexFile::Get both indicate 
that

recording.h is unpatched.

In vdr-1.6.0-2-tsplay-0.1.diff you will find the modifications to 
recording.h

starting at line 1376.



Sorry Frank - definitely patched.  I just tried cleaning and recompiling 
everything, don't seem to be getting the IsPesRecording function error, but 
am still getting the cIndexFile mismatch:


server/recplayer.c: In member function 'uint64_t 
cRecPlayer::positionFromFrameNumber(uint32_t)':
server/recplayer.c:253: error: no matching function for call to 
'cIndexFile::Get(int, uchar*, int*)'
../../../include/vdr/recording.h:229: note: candidates are: bool 
cIndexFile::Get(int, uint16_t*, off_t*, uchar*, int*)
../../../include/vdr/recording.h:231: note: int 
cIndexFile::Get(uint16_t, off_t)

make: *** [server/recplayer.o] Error 1

I don't get it - it's calling a Get(int, uchar*, int*), which are defined 
Get(int, uint16_t*, off_t*, uchar*, int*)  ??




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TS Play Plugin - breaks streamdev and radio plugins

[Simon Baxter]

The tsplay patch adds this member to VDR's cRecording class. So probably 
the
header files are not up-to-date. Try a "make include-dir" in the VDR 
source

directory, then recompile streamdev.


Nope, same problem:

make include-dir
make plugins

server/recplayer.c: In constructor 'cRecPlayer::cRecPlayer(const 
cRecording*)':
server/recplayer.c:38: error: 'const class cRecording' has no member named 
'IsPesRecording'
server/recplayer.c: In member function 'uint64_t 
cRecPlayer::positionFromFrameNumber(uint32_t)':
server/recplayer.c:253: error: no matching function for call to 
'cIndexFile::Get(int, uint16_t*, off_t*)'
../../../include/vdr/recording.h:215: note: candidates are: bool 
cIndexFile::Get(int, uchar*, int*, uchar*, int*)
../../../include/vdr/recording.h:217: note: int 
cIndexFile::Get(uchar, int)

make[1]: *** [server/recplayer.o] Error 1
make[1]: Leaving directory `/root/vdr-1.6.0/PLUGINS/src/streamdev'



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] GCC error messages [was: TS Play Plugin - breaksstreamdev and radio plugins]

[Simon Baxter]

Hi

This is an off topic answer!

Am Montag, 12. April 2010 schrieb Simon Baxter:
> (on an off topic, I've never worked out why gcc puts â instead of ' - 
> gcc

> seems to be the only thing that does it!)

I don't know why, but it seems GCC tries to localize the error messages. I
noticed that using:

shell prompt$ LANG=C make 

gives error messages that are plain ASCII and readable :)

Regards
Dieter


Thanks 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Ring Buffer Overflow with streamdev

[Simon Baxter]

Приветствую, Simon

may be you will happy with
http://trac.xbmc.org/browser/branches/pvr-testing2/xbmc/pvrclients/vdr-vnsi/vdr-plugin-vnsiserver?rev=29133



Is this likely to replace the XBMC streamdev interface?  I can find very 
little on the web about this "vnsi" and there's few helps or documentation 
yet.


First attempt, I'm getting these errors on the VDR console with vnsi:
NSI Server started
Client with ID 0 connected: 127.0.0.1:34215
Welcome client '' with protocol version '1'
ERR Action - processPacket exited with fail
ERR Action - processPacket exited with fail
ERR Action - processPacket exited with fail
ERR Action - processPacket exited with fail
ERR Action - processPacket exited with fail
ERR Action - processPacket exited with fail
ERR read - cxSocket::read: read() error at 0/4
ERR Action - THREAD ENDED
Client with ID 0 seems to be disconnected, removing from client list

I can see recordings on the VDR server, but the above errors occur when I 
try and watch live-TV.


I'm starting VDR with just -P'vnsiserver'

What does "processPacket exited with fail" mean? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TS Play Plugin - breaks streamdev and radio plugins

[Simon Baxter]

Should be fine - is it still failing?


yes, the streamdev compile now fails with with:

server/recplayer.c: In constructor âcRecPlayer::cRecPlayer(const 
cRecording*)â:
server/recplayer.c:38: error: âconst class cRecordingâ has no member named 
âIsPesRecordingâ
server/recplayer.c: In member function âuint64_t 
cRecPlayer::positionFromFrameNumber(uint32_t)â:
server/recplayer.c:253: error: no matching function for call to 
âcIndexFile::Get(int, uint16_t*, off_t*)â
../../../include/vdr/recording.h:215: note: candidates are: bool 
cIndexFile::Get(int, uchar*, int*, uchar*, int*)
../../../include/vdr/recording.h:217: note: int 
cIndexFile::Get(uchar, int)

make[1]: *** [server/recplayer.o] Error 1
make[1]: Leaving directory `/root/vdr-1.6.0/PLUGINS/src/streamdev'


(on an off topic, I've never worked out why gcc puts â instead of ' - gcc 
seems to be the only thing that does it!)




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TS Play Plugin - breaks streamdev and radio plugins

[Simon Baxter]

in streamdev's server/recplayer.c, replacing "#if {API,VDR}VERSNUM >= 
10703"

by "#if 1" and "#if APIVERSNUM < 10703" by "#if 0" should do the trick.


Have I got this wrong?

[r...@freddy server]# diff recplayer.c recplayer.c.orig
37c37
< #if 1
---

#if VDRVERSNUM >= 10703

61c61
< #if 0
---

#if APIVERSNUM < 10703

102c102
< #if 1
---

#if APIVERSNUM >= 10703

138c138
< #if 0
---

#if APIVERSNUM < 10703

245c245
< #if 1
---

#if VDRVERSNUM >= 10703



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] TS Play Plugin - breaks streamdev and radio plugins

[Simon Baxter]

Hi

I'm trying to use Udo Richter's plugin to play .ts recordings in vdr-1.6.0 
(http://www.udo-richter.de/vdr/patches.en.html) but it breaks a couple of 
plugins


streamdev plugin:

server/recplayer.c: In member function âuint64_t 
cRecPlayer::positionFromFrameNumber(uint32_t)â:
server/recplayer.c:253: error: no matching function for call to 
âcIndexFile::Get(int, uchar*, int*)â
../../../include/vdr/recording.h:229: note: candidates are: bool 
cIndexFile::Get(int, uint16_t*, off_t*, uchar*, int*)
../../../include/vdr/recording.h:231: note: int 
cIndexFile::Get(uint16_t, off_t)

make: *** [server/recplayer.o] Error 1

radio plugin:

g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE 
-DPLUGIN_NAME_I18N='"radio"' -I../../../include -I/include radio.c

radio.c: In member function âvirtual bool cPluginRadio::Start()â:
radio.c:493: error: cannot allocate an object of abstract type âcRadioAudioâ
radioaudio.h:71: note:   because the following virtual functions are pure 
within âcRadioAudioâ:
../../../include/vdr/audio.h:27: note:  virtual void cAudio::PlayTs(const 
uchar*, int)

make: *** [radio.o] Error 1


Has anyone resolved this?


Thx


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Ring Buffer Overflow with streamdev

[Simon Baxter]

Hi

Am running the latest streamdev cvs, patched with
http://cobradevil.org/downloads/streamdev-xbmc.patch
but am getting frozen live video (recordings are fine) in XBMC and the 
following:


Mar 30 06:27:35 freddy vdr: [12662] ERROR: 1 ring buffer overflow (188 
bytes dropped)
Mar 30 06:27:41 freddy vdr: [12662] ERROR: 51 ring buffer overflows (9588 
bytes dropped)
Mar 30 06:27:47 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:53 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:59 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:05 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:10 freddy vdr: [12856] streamdev-livestreaming thread ended 
(pid=12656, tid=12856)
Mar 30 06:28:10 freddy vdr: [12855] streamdev-writer thread ended 
(pid=12656, tid=12855)

Mar 30 06:28:10 freddy vdr: [12674] buffer stats: 63920 (1%) used

How do I diagnose?

Can I expand the buffer (even temporarily) to see if this is what's 
causing the frozen video?


Any other ideas?



I've just tried running vdr-1.7.14 with (s2-liplianin drivers) the same 
version on streamdev and xbmc, all on the local machine running 
2.6.27.30-170.2.82.fc10.x86_64.  Have also installed on another machine 
running 2.6.27.29-170.2.78.fc10.x86_64.


Am still getting the same results, with "ring buffer overflow" messages and 
frozen picture after 3-5 seconds.  Again, playing recordings works fine.


Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Ring Buffer Overflow with streamdev (was XBMC with vdr-1.6.0 ??)

[Simon Baxter]

Hi

Am running the latest streamdev cvs, patched with
http://cobradevil.org/downloads/streamdev-xbmc.patch
but am getting frozen live video (recordings are fine) in XBMC and the 
following:


Mar 30 06:27:35 freddy vdr: [12662] ERROR: 1 ring buffer overflow (188 bytes 
dropped)
Mar 30 06:27:41 freddy vdr: [12662] ERROR: 51 ring buffer overflows (9588 
bytes dropped)
Mar 30 06:27:47 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:53 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:59 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:05 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:10 freddy vdr: [12856] streamdev-livestreaming thread ended 
(pid=12656, tid=12856)
Mar 30 06:28:10 freddy vdr: [12855] streamdev-writer thread ended 
(pid=12656, tid=12855)

Mar 30 06:28:10 freddy vdr: [12674] buffer stats: 63920 (1%) used

How do I diagnose?

Can I expand the buffer (even temporarily) to see if this is what's causing 
the frozen video?


Any other ideas?


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

> Updated to [XBMC] 28276 and have exactly the same problem.  Only 3-5
> seconds of video when switching to LiveTV...but recordings now play OK.
>
> ??

Have noticed that the video freezes at the same time as I get the 
following

in /var/log/messages:

Mar 29 22:11:31 freddy vdr: [11020] ERROR: 1 ring buffer overflow (188 
bytes

dropped)
Mar 29 22:11:37 freddy vdr: [11020] ERROR: 51 ring buffer overflows (9588
bytes dropped)
Mar 29 22:11:43 freddy vdr: [11020] ERROR: 60 ring buffer overflows 
(11280

bytes dropped)

(XBMC is running on the same machine as VDR)

Goga777, looking at thread:
http://forum.xbmc.org/showthread.php?t=45314&page=51

I'm running streamdev:
vdr-plugin-streamdev_0.5.0~pre20090706+cvs20100307.2102.orig.tar.gz
which should already have patch "streamdev-cvs221109-AddFemonV1.diff"
applied

Have you seen this before??



please try cvs version of streamdev plugin  + cumulate patch which I 
mention in my previous mail


Goga


Pulled the latest cvs, patched with 
http://cobradevil.org/downloads/streamdev-xbmc.patch still get frozen live 
video in XBMC and the following:


Mar 30 06:27:35 freddy vdr: [12662] ERROR: 1 ring buffer overflow (188 bytes 
dropped)
Mar 30 06:27:41 freddy vdr: [12662] ERROR: 51 ring buffer overflows (9588 
bytes dropped)
Mar 30 06:27:47 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:53 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:59 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:05 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:10 freddy vdr: [12856] streamdev-livestreaming thread ended 
(pid=12656, tid=12856)
Mar 30 06:28:10 freddy vdr: [12855] streamdev-writer thread ended 
(pid=12656, tid=12855)

Mar 30 06:28:10 freddy vdr: [12674] buffer stats: 63920 (1%) used

Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

Hi

Updated to [XBMC] 28276 and have exactly the same problem.  Only 3-5 
seconds of video when switching to LiveTV...but recordings now play OK.


??


Have noticed that the video freezes at the same time as I get the following 
in /var/log/messages:


Mar 29 22:11:31 freddy vdr: [11020] ERROR: 1 ring buffer overflow (188 bytes 
dropped)
Mar 29 22:11:37 freddy vdr: [11020] ERROR: 51 ring buffer overflows (9588 
bytes dropped)
Mar 29 22:11:43 freddy vdr: [11020] ERROR: 60 ring buffer overflows (11280 
bytes dropped)


(XBMC is running on the same machine as VDR)

Goga777, looking at thread:
http://forum.xbmc.org/showthread.php?t=45314&page=51

I'm running streamdev:
vdr-plugin-streamdev_0.5.0~pre20090706+cvs20100307.2102.orig.tar.gz
which should already have patch "streamdev-cvs221109-AddFemonV1.diff" 
applied


Have you seen this before??


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

please try to test with revision 28276 (it's last stable not broken 
revision. Currently xbmc developpers

don't recommend to use current svn version)

svn update -r28276


Hi

Updated to 28276 and have exactly the same problem.  Only 3-5 seconds of 
video when switching to LiveTV...but recordings now play OK.


?? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

Well, I've tried the patched version above, and it is better.  I now seem 
to

be able to switch between live channels in XBMC, but still only get a few
seconds of video/audio then the stream freezes.


don't know why you have so strange behaviour

which xbmc-pvr version do you have ?



I checked out revision 28472 on 9th March 2010



ALSO - how do I activate femon in XMBC?  I'm running the plugin in VDR, 
but

can't bring up this screen:


- TV settings - to show snr
- choice Pm3 skin
- tune on channel
- the button - info
- when we will see the service info, let's press Left button - we will see 
the femon info



Thanks - that helps!

Any other suggestions? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

Приветствую, Simon

please try to use this cumulate patch for streamdev-plugin from cvs

http://cobradevil.org/downloads/streamdev-xbmc.patch

or try to use the patched version of streamdev plugin
ftp://elcom.kaluga.ru/pub/downloads/streamdev-2010-02-14.tar.gz


also there's possibility to watch the femon information on xbmc-pvr


Well, I've tried the patched version above, and it is better.  I now seem to 
be able to switch between live channels in XBMC, but still only get a few 
seconds of video/audio then the stream freezes.


Can you send me your VDR config for streamdev from setup.conf?  (mine below)


streamdev-server.AllowSuspend = 1
streamdev-server.HTTPBindIP = 127.0.0.1
streamdev-server.HTTPServerPort = 3000
streamdev-server.HTTPStreamType = 1
streamdev-server.IGMPBindIP = 0.0.0.0
streamdev-server.IGMPClientPort = 1234
streamdev-server.IGMPStreamType = 0
streamdev-server.MaxClients = 5
streamdev-server.ServerPort = 2004
streamdev-server.StartHTTPServer = 1
streamdev-server.StartIGMPServer = 0
streamdev-server.StartServer = 1
streamdev-server.SuspendMode = 0
streamdev-server.VTPBindIP = 127.0.0.1


ALSO - how do I activate femon in XMBC?  I'm running the plugin in VDR, but 
can't bring up this screen:



have a look on screenshot
http://cobradevil.org/downloads/screenshot002.png



Thanks!
Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

On 25/03/2010 20:03, Simon Baxter wrote:


Apart from youe eac3 mods etc, does streamdev _actually_need_ any
patching to work with xbmc pvr-testing2? Or should
http://ppa.launchpad.net/hotzenplotz5/test-vdr-lucid/ubuntu/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.5.0~pre20090706+cvs20100307.2102.orig.tar.gz

work fine just compiled with no patches etc?


Honestly I don't know. And that's why using prepackaged set of patches 
avoid omitting necessary fixes and most of the time going into trouble in 
general.


BTW: Once configured, xbmc pvr-testing2, works for SD, epg,... but lacks 
programming feature and fails for me for HDTV. I dunno if my streamdev 
really works with HDTV or if its the rendering part that is not able to 
use VDPAU... As vdr record the HDTV streams correctly, I suppose streamdev 
should only write the TS stream on a socket instead than on the disk.


--eric


Have tried that streamdev, and I'm still getting the same problems.  I only 
get a picture and audio for a few seconds.


Can you send me your settings from VDR setup.conf?  Here's mine..

streamdev-server.AllowSuspend = 1
streamdev-server.HTTPBindIP = 127.0.0.1
streamdev-server.HTTPServerPort = 3000
streamdev-server.HTTPStreamType = 1
streamdev-server.IGMPBindIP = 0.0.0.0
streamdev-server.IGMPClientPort = 1234
streamdev-server.IGMPStreamType = 0
streamdev-server.MaxClients = 5
streamdev-server.ServerPort = 2004
streamdev-server.StartHTTPServer = 1
streamdev-server.StartIGMPServer = 0
streamdev-server.StartServer = 1
streamdev-server.SuspendMode = 0
streamdev-server.VTPBindIP = 127.0.0.1


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdraepg.rb not working [RESOLVED]

[Simon Baxter]

printchannels.pl -c /etc/vdr/vdr-1.6.0/channels.conf  gives me the 
channels I want to copy to/from:

ONE;T   C-182-10-1005
TV2;T   C-182-10-1006
TV3;T   C-182-0-1003
Prime TV;T  C-182-2-212
C4;TC-182-6-609


ONE_A   C-0-112-1796
TV2_A   C-0-119-1908
TV3_A   C-0-126-2020
Prime TV_A  C-0-189-2134
C4_AC-0-203-2135



Resolved this.

printchannels.pl was outputting the wrong channel details for ONE_A etc.

LSTC 101
250 101 ONE_A:112250:C0:C:0:301:300:305:A1:1796:0:1033:0

So printchannels.pl should have outputted:
ONE_A   C C-0-1033-1796

:) 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] vdraepg.rb not working

[Simon Baxter]

I only just recently discovered this script for copying EPG from one channel to 
another.

I have a couple of DVB-C cards, and use the PVRINPUT plugin to drive a PVR-500 
dual analog card.

I can't get this to work though.

printchannels.pl -c /etc/vdr/vdr-1.6.0/channels.conf  gives me the channels I 
want to copy to/from:
ONE;T   C-182-10-1005
TV2;T   C-182-10-1006
TV3;T   C-182-0-1003
Prime TV;T  C-182-2-212
C4;TC-182-6-609


ONE_A   C-0-112-1796
TV2_A   C-0-119-1908
TV3_A   C-0-126-2020
Prime TV_A  C-0-189-2134
C4_AC-0-203-2135


So I put this into /vdraepg.conf :
#source-channel, target-channel, time-adjustment
C-182-10-1005, C-0-112-1796, 0 #ONE;C -> ONE_A
C-182-10-1006, C-0-119-1908, 0 #TV2;C -> TV2_A
C-182-0-1003, C-0-126-2020, 0 #TV3;C -> TV3_A
C-182-2-212, C-0-189-2134, 0 #PRIME;C -> PRIME TV_A
C-182-6-609, C-0-203-2135, 0 #C3;C -> C4_A

but when I run:
/root/bin/vdraepg.rb -s /root/bin -c /etc/vdr/vdr-1.6.0

I get these messages (which look OK):
250 EPG data processed
221 freddy.nzbaxters closing connection

But no epg data is transfered


What am I doing wrong?___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

No not really. I used the code prepackaged from here



Not the pre compiled packages themselves because I needed the eac3 modif 
in it but as you have the original tar ball, + the debian patches taht 
create a debian directory and in the debian directory you find a 
subdirectory patches that is aplied bafore compilation you get the picture 
(+ as I use debian I just have to apply the patches and use the build 
system)


But yo can easill get the sources for any linux system and the configure 
options given.


Thanks Eric

Apart from youe eac3 mods etc, does streamdev _actually_need_ any patching 
to work with xbmc pvr-testing2?  Or should 
http://ppa.launchpad.net/hotzenplotz5/test-vdr-lucid/ubuntu/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.5.0~pre20090706+cvs20100307.2102.orig.tar.gz

work fine just compiled with no patches etc?


-Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

Does anyone have this working with vdr-1.6.0?


No but I do have it with a patched vdr 1.7.14 + streamdev to support 
french HD TV (VC1 + eac3)


--eric


Thanks Eric

Did you patch streamdev, or is this only necessary if you need parental 
controls etc?


If I run it (with 1.6.0) with unpatched streamdev, I only get video/audio 
for a few seconds then XBMC freezes.  If I run it with patched streamdev, I 
can't connect to live TV at all.


Any clues?

Where do you get most of your support for this?  The XMBC linux forum, or 
somewhere else?



Thx
Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

Rob wrote:
The pvr-testing2 version of xbmc works with 1.6.0 (or did three weeks 
ago) as long as you have a recent streamdev patched..





Does anyone have this working with vdr-1.6.0?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Can't open recordings in xbmc with streamdev and vdr-1.6

[Simon Baxter]

Hi

Maybe not a VDR issue?  But just maybe?

I can't get recordings to play via the LiveTV front end in pvr-testing.  I 
get the following xbmc messages.


13:49:42 T:140497893411024 M:1689784320  NOTICE: DVDPlayer: Opening: 
pvr://recordings/client_0001/ARCHIVE/Judge Alex/Judge Alex-00074.pvr
13:49:42 T:140497893411024 M:1689784320 WARNING: 
CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
13:49:42 T:140497672808784 M:1689784320   DEBUG: thread start, auto delete: 
0

13:49:42 T:140497672808784 M:1689784320  NOTICE: Creating InputStream
13:49:42 T:140497893411024 M:1690079232   DEBUG: -- Window Init 
(DialogBusy.xml) --
13:49:42 T:140497893411024 M:1690079232INFO: Loading skin file: 
DialogBusy.xml
13:49:43 T:140497893411024 M:1690079232   DEBUG: Load DialogBusy.xml: 
13.77ms
13:49:43 T:140497893411024 M:1690079232   DEBUG: Alloc resources: 14.10ms 
(14.10 ms skin load)
13:49:43 T:140497672808784 M:1689550848   DEBUG: AddOnLog: 
pvrclient/VDRClient for streamdev: CVTPTransceiver::CreateDataConnection - 
local address 127.0.0.1

:44950
13:49:43 T:140497672808784 M:1689550848   DEBUG: AddOnLog: 
pvrclient/VDRClient for streamdev: CVTPTransceiver::OpenStreamSocket - 
listening on 0.0.0.0:38286
13:49:43 T:140497672808784 M:1689550848   DEBUG: Open - Recording has 
started on filename pvr://recordings/client_0001/ARCHIVE/Judge Alex/Judge 
Alex-00074.pv

r
13:49:43 T:140497672808784 M:1689550848  NOTICE: Creating Demuxer
13:49:43 T:140497672808784 M:1689550848   DEBUG: 
SECTION:LoadDLL(special://xbmc/system/players/dvdplayer/avutil-50-x86_64-linux.so)
13:49:43 T:140497672808784 M:1689550848   DEBUG: Loading: 
/usr/local/share/xbmc/system/players/dvdplayer/avutil-50-x86_64-linux.so
13:49:43 T:140497672808784 M:1689591808   DEBUG: 
SECTION:LoadDLL(special://xbmc/system/players/dvdplayer/avcodec-52-x86_64-linux.so)
13:49:43 T:140497672808784 M:1689591808   DEBUG: Loading: 
/usr/local/share/xbmc/system/players/dvdplayer/avcodec-52-x86_64-linux.so
13:49:43 T:140497672808784 M:1689497600   DEBUG: 
SECTION:LoadDLL(special://xbmc/system/players/dvdplayer/avformat-52-x86_64-linux.so)
13:49:43 T:140497672808784 M:1689497600   DEBUG: Loading: 
/usr/local/share/xbmc/system/players/dvdplayer/avformat-52-x86_64-linux.so



And the screen sits on "working..."

Can anyone suggest anything??

Thanks
Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

The pvr-testing2 version of xbmc works with 1.6.0 (or did three weeks ago) 
as long as you have a recent streamdev patched..




I'm having a problem with the plugin

It connects OK, but I only get a few seconds of video/audio then it freezes.

xbmc.log has:
10:23:48 T:140535683545424 M:1723899904   DEBUG: 
CDVDPlayer::HandleMessages - player started 1
10:23:48 T:140535683545424 M:1723899904   DEBUG: CDVDPlayer::SetCaching - 
caching state 3
10:23:48 T:140535459158352 M:1723899904   ERROR: GetDelay - snd_pcm_delay, 
alsa error: -32 - Broken pipe
10:23:48 T:140535683545424 M:1723899904   DEBUG: CDVDPlayer::SetCaching - 
caching state 0
10:23:48 T:140535459158352 M:1723899904   DEBUG: CDVDPlayerAudio:: 
Discontinuity - was:775.65, should be:0.33, error:-775.32
10:23:49 T:140535807903952 M:1722826752INFO: GL: ARB Imaging extension 
supported
10:23:49 T:140535459158352 M:1721577472   DEBUG: CDVDPlayerAudio:: 
Discontinuity - was:1002877.37, should be:1018548.526184, 
error:15671.152851
10:23:49 T:140535683545424 M:1721577472   DEBUG: 
CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/4.pvr)
10:23:50 T:140535683545424 M:1720696832   DEBUG: 
CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/4.pvr)
10:23:51 T:140535459158352 M:1719939072 WARNING: 
CDVDMessageQueue(audio)::Get - retrieved last data packet of queue
10:23:51 T:140535469648208 M:1719939072 WARNING: 
CDVDMessageQueue(video)::Get - retrieved last data packet of queue
10:23:52 T:140535469648208 M:1719939072INFO: CDVDPlayerVideo - 
Stillframe detected, switching to forced 25.00 fps
10:23:53 T:140535683545424 M:1719947264INFO: AddOnLog: 
pvrclient/VDRClient for streamdev: No data in 2 seconds, queuing no signal 
image


any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

- Original Message - 
From: "scott" 

To: "VDR Mailing List" 
Sent: Monday, March 08, 2010 9:45 PM
Subject: Re: [vdr] XBMC with vdr-1.6.0 ??



One way thats been suggested before, and which I use, is to put xbmc and
vdr-xine in a while loop inside a bash shell script and set up a button to
stop vdr-xine, and a menu option in xbmc to close it down.  If you search
this thread you should find some info, if not I can post my stuff.

--
Scott


Thanks Scott.  Yes please, would like to see how you've implemeted it.

I found a number of threads and have achieved the following:
* added a script (vdr.py) under the My Scripts which calls the xine 
frontend.  But this flags an error "Errors in system config" or similar, 
launches xine but closes xbmc at the back end

http://forum.xbmc.org/showthread.php?t=42205

* added a phantom button on the main menu, which I'd hoped would launch 
vdr-py (lower in the above thread).  But this just crashes xmbc


What I want to achieve is a main menu button which launches an external bash 
script, to launch xine, which keeps xbmc running in the background.  I 
currently have mms running like this and it works really well.  I then use 
the "power" button to kill xine (and turn off lirc), and fall back to mms.



Thanks
Simon


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] XBMC with vdr-1.6.0 ??

[Simon Baxter]

Hi

Has anyone got XBMC working with vdr-1.6.0?

I want to run XBMC, but am not ready to move to a .ts file format yet.  So I 
was thinking I'd just get XMBC to call a script and run vdr-xine (ie not 
integrate with streamdev etc).  This should be easy yes?



Any pointers or experience?

Thanks
Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xine vdpau not working?

[Simon Baxter]

Theunis Potgieter Said:
I think it is your card that is the problem

http://en.wikipedia.org/wiki/VDPAU shows that is should support up to
VP1, however if you look at mythtv's guide:
http://www.mythtv.org/wiki/VDPAU it starts only at series 8 and newer.

It seems that your card can then only support xvmc for mpeg2 codec only. 
:(


Buy a a new 8400 GS (old brand model name but new architecture G98
chip) as indicated here http://en.wikipedia.org/wiki/Nvidia_PureVideo


I've tried it in my production machine now, which has this card:
03:00.0 VGA compatible controller: nVidia Corporation GeForce 8400 GS (rev 
a1) (prog-if 00 [VGA controller])

   Subsystem: Giga-byte Technology Device 3463
   Flags: bus master, fast devsel, latency 0, IRQ 16
   Memory at ea00 (32-bit, non-prefetchable) [size=16M]
   Memory at d000 (64-bit, prefetchable) [size=256M]
   Memory at e800 (64-bit, non-prefetchable) [size=32M]
   I/O ports at b000 [size=128]
   [virtual] Expansion ROM at eb00 [disabled] [size=128K]
   Capabilities: [60] Power Management version 2
   Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ 
Count=1/1 Enable-

   Capabilities: [78] Express Endpoint, MSI 00
   Capabilities: [100] Virtual Channel 
   Capabilities: [128] Power Budgeting 
   Capabilities: [600] Vendor Specific Information 
   Kernel driver in use: nvidia
   Kernel modules: nvidiafb, nvidia


And while vdpau does work now, I get little CPU improvement (drops from ~60% 
under xv to ~45% on vdpau), there's some tearing during action scenes and 
some image freezing for a few seconds when switching from live TV to 
recordings which I've had to "kill" on occasion.


Currently I only have SD content to watch and my Sony Bravia 32V only 
supports up to 1360x668.  Any point using vdpau?





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-xine - skipping audio & video [RESOLVED]

[Simon Baxter]

Will try it out and let you know...


- Original Message - 
From: "Theunis Potgieter" 

To: "VDR Mailing List" 
Sent: Sunday, January 10, 2010 5:49 AM
Subject: Re: [vdr] vdr-xine - skipping audio & video [RESOLVED]


I got this information from Pertti and it helped me with my sync
problems, but I see your audio.synchronization.resample_mode is set to
on instead of off. Does off make a difference for you?

2009/12/4 Pertti Kosunen :

Theunis Potgieter wrote:


button (jump to a specific time). All the xineliboutput versions seems to
do this and, xine-lib-1.2 also does this. problem must be with the 
plug-in

it self and similar to yours?


audio.synchronization.av_sync_method:resample
audio.synchronization.resample_mode:off

Try with these options in xine's config.



2010/1/9 Simon Baxter :

Fix: (too easy, as these things often turn out to be!!!) modify
~/.xine.config
from:
audio.synchronization.av_sync_method:0
audio.synchronization.resample_mode:0
to:
audio.synchronization.av_sync_method:resample
audio.synchronization.resample_mode:on

HOORAY!!! I'm finally able to move off a 2007 plugin!



___
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] xine vdpau not working?

[Simon Baxter]

SB said:
OK, so I installed the headers and everything compiles and looks OK.  But



main: probing  video output plugin
vo_vdpau: Can't create vdp device : No vdpau implementation.
load_plugins: plugin vdpau_mpeg12 failed to instantiate itself.
main: video driver  failed


I've moved to my production box and vdpau works there - looks like my 
development box video card won't support.


So xine-1.6.0, vdr-xine-0.9.3 and vdpau works - which is a move forward.

But VDR doesn't work as well as under xv.  It's slower changing channels and 
watching (SD) recordings freezes things for a few seconds.  Also, the 
quality is actually worse - during "action scenes" objects seem to be a bit 
jerky and have "lines" momentarily.  Only advantage, under vdpau the cpu 
sits at about 40%, where under xv it sits 50-70%.


Any thoughts? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xine vdpau not working?

[Simon Baxter]

On Sat, Jan 9, 2010 at 1:25 AM, Simon Baxter  
wrote:


I'm using xine-lib-1.2 and patching with xine-lib-1.2-vdpau-r286.diff 
which


There is no need to do such thing, since there already exists a
repository which contains vdpau: xine-lib/xine-lib-1.2-vdpau
You can use it as follows:
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2-vdpau

Otherwise, just pay attention to the messages you get when
configuring/compiling xine-lib.

-Petri


OK, so I installed the headers and everything compiles and looks OK.  But 
when I try and run xine get:


#grep vdpau* xine_log

load_plugins: plugin vdpau_mpeg12 failed to instantiate itself.
load_plugins: plugin 
/usr/local/lib/xine/plugins/2.0/xineplug_decode_vdpau_mpeg12.so found
load_plugins: plugin 
/usr/local/lib/xine/plugins/2.0/xineplug_decode_vdpau_vc1.so found
load_plugins: plugin 
/usr/local/lib/xine/plugins/2.0/xineplug_decode_vdpau_h264.so found
load_plugins: plugin 
/usr/local/lib/xine/plugins/2.0/xineplug_vo_out_vdpau.so found

main: probing  video output plugin
vo_vdpau: Can't create vdp device : No vdpau implementation.
load_plugins: plugin vdpau_mpeg12 failed to instantiate itself.
main: video driver  failed

Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-xine - skipping audio & video [RESOLVED]

[Simon Baxter]

Hi

After literally a year or more, I've finally found the one thing that was
causing my problems with this.

Problem: Any version of vdr-xine above 0.8.0 (and associated xine-lib and
xine-ui from Reinhard's website) caused audio and video skips a few minutes
into watching a recording.  This was indicated by multiple "fixing sound
card drift by  pts" messages in the xine console coinciding with the
video "catching up"

Fix: (too easy, as these things often turn out to be!!!) modify
~/.xine.config
from:
audio.synchronization.av_sync_method:0
audio.synchronization.resample_mode:0
to:
audio.synchronization.av_sync_method:resample
audio.synchronization.resample_mode:on

HOORAY!!!  I'm finally able to move off a 2007 plugin!


Next problem - I can't get vdpau to work.  But I'll start another thread for
that.


Regards
Simon

- Original Message - 
From: "Simon Baxter" 

To: "VDR Mailing List" 
Sent: Sunday, October 18, 2009 9:57 PM
Subject: [vdr] vdr-xine - skipping audio & video



Hi - am at my wits end!!!

I've now tried vdr-xine-0.9.3 with XV and with VDPAU, and several settings 
in .xine/config for engine.buffers.audio_num_buffers (2300) and 
engine.buffers.video_num_frames (60) but I still get skips in audio and 
video when viewing recorded programs - which I don't get in 
vdr-xine-0.8.0.


The skips occur at the same time as VDR console messages "buffering xx 
frames", and start out OK when watching the program but within a few 
minutes deteriorate further and further.


I've been trying to upgrade from 0.8.0 since 2007 now - but it's the only 
version which works flawlessly for me.


My production box has:
vdr-1.6.0
fedora 10 with latest kernel
fluxbox and X window manager
latest standard v4l-dvb drivers
plugins: vdr-xine-0.8.0, iptv, epgsearch, skinenigmang, femon, radio, 
recstatus, pvrinput.

xine started with :
xine --no-splash -Bfpqg --hide-gui -r anamorphic -V 
xv -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 
 --post vdr_video --post vdr_audio 
vdr://tmp/vdr-xine/stream#demux:mpeg_pes



I've tested the following
vdr-1.7.9 with the s2-liplianin drivers
vdr-1.7.9 with the standard latest v4l-dvb drivers
vdr-xine various versions from 0.8.1 right up to 0.9.3
xine-lib-1.2 with VDPAU and with XV output started by either:
xine --no-splash -Bfpqg --hide-gui -r anamorphic -V 
vdpau -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 
 --post vdr_video --post vdr_audio vdr://tmp/vdr-xine/stream#dex:mpeg_pes

OR
xine --no-splash -Bfpqg --hide-gui -r anamorphic -V 
xv -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 
 --post vdr_video --post vdr_audio 
vdr://tmp/vdr-xine/stream#demux:mpeg_pes



Can someone share their experiences with VDPAU and vdr-xine, or offer any 
suggestions???


Thanks
Simon

___
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] vdr-xine 0.9.3 audio problems [RESOLVED]

[Simon Baxter]

Hi

After literally a year or more, I've finally found the one thing that was 
causing my problems with this.


Problem: Any version of vdr-xine above 0.8.0 (and associated xine-lib and 
xine-ui from Reinhard's website) caused audio and video skips a few minutes 
into watching a recording.  This was indicated by multiple "fixing sound 
card drift by  pts" messages in the xine console coinciding with the 
video "catching up"


Fix: (too easy, as these things often turn out to be!!!) modify 
~/.xine.config

from:
audio.synchronization.av_sync_method:0
audio.synchronization.resample_mode:0
to:
audio.synchronization.av_sync_method:resample
audio.synchronization.resample_mode:on

HOORAY!!!  I'm finally able to move off a 2007 plugin!


Next problem - I can't get vdpau to work.  But I'll start another thread for 
that.



Regards
Simon

- Original Message - 
From: "Reinhard Nissl" 

To: "VDR Mailing List" 
Sent: Monday, October 05, 2009 10:29 AM
Subject: Re: [vdr] vdr-xine 0.9.3 audio problems



Hi,

Simon Baxter schrieb:


#engine.buffers.video_num_buffers is left at the default of 500.  If I
set this any higher, fast forwarding or rewinding causes the video to
jump about 90 seconds.


VDR-1.7.x should address this.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de

___
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] CAM auto resetting - feature request??

[Simon Baxter]

I've discovered this happens to both CAMs, so it's either not a hardware
issue, or both CAMs are affected.

Managed to capture the following logs prior to the CAM dropping from
"AlphaCrypt" to "CAM Ready" (with no decrypting)



This looks more like a driver bug to me.

Klaus



Can I do a "CAM Reset" from svdrp?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdpau setup steps for vdr client

[Simon Baxter]

I have two problems with playback:  
First main problem is audio sync, which while playing a recording the audio 
slips further and further out of sync after 5 or more minutes.  Then the video 
skips to catch up and I get a gap in the program (very disconcerting when 
you're trying to follow the programme!!).  These skips seem to occur 
coincidentally when console messages say "buffered 6.3 frames (v:10.9, a:6.3)"

Second problem is more similar to several other people, and possibly yours, 
where if I FF/REW a playback, when I hit play again it jumps "minutes" making 
FF/REW very inaccurant.


  I experience the audio sync problems when I fast forward or rewind 
recordings, or when I press green/yellow (jump 1 minute back/forward) or press 
7 or 9 between markings, this is however the problem with xineliboutput. Only 
way to fix playback audiosync is by pressing the red button (jump to a specific 
time). All the xineliboutput versions seems to do this and, xine-lib-1.2 also 
does this. problem must be with the plug-in it self and similar to yours?


  2009/12/3 Simon Baxter 

  I wouldn't bother upgrading, to be honest.

  I've had several attempts to upgrade to 1.7 and VDPAU - but consistently 
get audio/video sync problems with live video and issues with indexing during 
rewinding/forwarding during playback.  Have spent more hours than I care to say 
trying to fix this, only to downgrade again.

  vdr-1.6.0 and xine-0.8.0 work just fine for me!!



To be fair to my comment above, I've had audio sync problems with live TV 
on all versions above vdr-xine-0.8.0 which is why I've never been able to run a 
newer version in production.  I've had several posts on this and tried 
everything anyone has suggested - but after an hour or my wife banging on about 
the poor quality, always downgrade back to VDR-1.6.0 and VDR-XINE-0.8.0

So I don't think my problems are related to VDPAU or VDR-1.7.x.


-Simon 


___
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdpau setup steps for vdr client

[Simon Baxter]

I wouldn't bother upgrading, to be honest.

I've had several attempts to upgrade to 1.7 and VDPAU - but consistently 
get audio/video sync problems with live video and issues with indexing 
during rewinding/forwarding during playback.  Have spent more hours than I 
care to say trying to fix this, only to downgrade again.


vdr-1.6.0 and xine-0.8.0 work just fine for me!!


To be fair to my comment above, I've had audio sync problems with live TV on 
all versions above vdr-xine-0.8.0 which is why I've never been able to run a 
newer version in production.  I've had several posts on this and tried 
everything anyone has suggested - but after an hour or my wife banging on 
about the poor quality, always downgrade back to VDR-1.6.0 and 
VDR-XINE-0.8.0


So I don't think my problems are related to VDPAU or VDR-1.7.x.


-Simon 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] mdadm software raid5 arrays?

[Simon Baxter]

But does anyone have any production VDR experience with mdadm - good or 
bad?


I've now tested and implemented RAID5 on my system.  The biggest CPU hit is 
still with the OSD or noad processes - below is a bunch of tests I ran and 
the top processes during the test:


1 recording to raid, watching another live
top - 07:52:18 up 1 day, 20:29,  3 users,  load average: 0.66, 0.54, 0.42
Tasks: 168 total,   2 running, 156 sleeping,  10 stopped,   0 zombie
Cpu(s): 20.2%us,  6.7%sy,  0.5%ni, 68.3%id,  1.5%wa,  0.5%hi,  2.4%si, 
0.0%st

Mem:   2059352k total,  2038636k used,20716k free,19724k buffers
Swap:  1903692k total,  292k used,  1903400k free,  1412672k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
2372 vdruser   20   0  542m  37m  18m S 37.1  1.9   1:09.50 xine
2330 vdruser   20   0  486m  26m 4616 S 10.6  1.3   0:21.68 vdr
3020 root  20   0  369m  24m  18m R  9.6  1.2 157:51.36 Xorg
3521 vdruser   20   0  923m 306m  25m S  1.0 15.3  50:59.10 mms
3723 root  15  -5 000 S  0.7  0.0  10:12.08 md0_raid5
2455 root  20   0 14880 1188  872 R  0.3  0.1   0:00.32 top
2593 root  15  -5 000 S  0.3  0.0   1:04.10 kdvb-ca-1:0
3168 vdruser   20   0  139m 5468 3984 S  0.3  0.3   6:03.34 fluxbox


2 recording to raid, watching another live
top - 07:55:09 up 1 day, 20:32,  3 users,  load average: 1.67, 1.00, 0.61
Tasks: 168 total,   1 running, 157 sleeping,  10 stopped,   0 zombie
Cpu(s): 21.8%us,  7.8%sy,  0.3%ni, 66.6%id,  0.7%wa,  0.7%hi,  2.1%si, 
0.0%st

Mem:   2059352k total,  203k used,20464k free,20732k buffers
Swap:  1903692k total,  292k used,  1903400k free,  1406060k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
2372 vdruser   20   0  542m  37m  18m S 39.4  1.9   2:17.04 xine
2330 vdruser   20   0  511m  32m 4616 S 13.9  1.6   0:45.66 vdr
3020 root  20   0  369m  24m  18m S  9.9  1.2 158:08.39 Xorg
3723 root  15  -5 000 S  1.3  0.0  10:14.20 md0_raid5
3521 vdruser   20   0  923m 306m  25m S  1.0 15.3  51:00.61 mms
2455 root  20   0 14880 1188  872 R  0.7  0.1   0:01.19 top
 271 root  20   0 000 S  0.3  0.0   0:09.16 pdflush


3 recording to raid, watching another live
top - 07:55:52 up 1 day, 20:32,  3 users,  load average: 1.69, 1.08, 0.65
Tasks: 168 total,   1 running, 157 sleeping,  10 stopped,   0 zombie
Cpu(s): 22.1%us,  7.2%sy,  0.5%ni, 68.1%id,  0.0%wa,  0.0%hi,  2.1%si, 
0.0%st

Mem:   2059352k total,  2040896k used,18456k free,20964k buffers
Swap:  1903692k total,  292k used,  1903400k free,  1401876k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
2372 vdruser   20   0  606m  37m  18m S 34.2  1.9   2:32.21 xine
2330 vdruser   20   0  536m  37m 4616 S 14.3  1.9   0:51.80 vdr
3020 root  20   0  369m  24m  18m S  9.6  1.2 158:12.50 Xorg
3723 root  15  -5 000 S  1.7  0.0  10:14.83 md0_raid5
2455 root  20   0 14880 1188  872 R  0.7  0.1   0:01.41 top
3168 vdruser   20   0  139m 5468 3984 S  0.7  0.3   6:04.13 fluxbox
3521 vdruser   20   0  923m 306m  25m S  0.7 15.3  51:00.98 mms


4 recording to raid, watching another live
top - 07:56:37 up 1 day, 20:33,  3 users,  load average: 1.89, 1.19, 0.71
Tasks: 168 total,   2 running, 156 sleeping,  10 stopped,   0 zombie
Cpu(s): 23.6%us,  8.0%sy,  0.3%ni, 66.3%id,  0.0%wa,  0.3%hi,  1.5%si, 
0.0%st

Mem:   2059352k total,  2042836k used,16516k free,21264k buffers
Swap:  1903692k total,  292k used,  1903400k free,  1393688k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
2372 vdruser   20   0  606m  38m  18m S 36.8  1.9   2:48.28 xine
2330 vdruser   20   0  583m  44m 4616 S 15.6  2.2   0:58.77 vdr
3020 root  20   0  369m  24m  18m S  9.0  1.2 158:16.78 Xorg
3723 root  15  -5 000 S  2.3  0.0  10:15.70 md0_raid5
3521 vdruser   20   0  923m 306m  25m S  1.0 15.3  51:01.39 mms
3168 vdruser   20   0  139m 5468 3984 S  0.7  0.3   6:04.30 fluxbox
2455 root  20   0 14880 1188  872 R  0.3  0.1   0:01.64 top
2593 root  15  -5 000 S  0.3  0.0   1:04.21 kdvb-ca-1:0
   1 root  20   0  4080  852  604 S  0.0  0.0   0:00.50 init


4 recording to raid, watching another live, OSD up
top - 07:57:19 up 1 day, 20:34,  3 users,  load average: 1.87, 1.28, 0.75
Tasks: 168 total,   1 running, 157 sleeping,  10 stopped,   0 zombie
Cpu(s): 32.6%us,  7.6%sy,  0.5%ni, 55.4%id,  1.1%wa,  0.2%hi,  2.6%si, 
0.0%st

Mem:   2059352k total,  2033996k used,25356k free,21516k buffers
Swap:  1903692k total,  292k used,  1903400k free,  1383424k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
2372 vdruser   20   0  603m  36m  15m S 57.9  1.8   3:05.55 xine
2330 vdruser   20   0  583m  45m 4616 S 12.9  2.2   1:05.39 vdr
3020 root  20   0  366m  20m  14m S  8.9  1.0 158:20.76 Xorg
3723 root  15  -5 000 S  2.3  0.0  10:16.61 md0_raid5

Re: [vdr] vdpau setup steps for vdr client

[Simon Baxter]

I wouldn't bother upgrading, to be honest.

I've had several attempts to upgrade to 1.7 and VDPAU - but consistently get 
audio/video sync problems with live video and issues with indexing during 
rewinding/forwarding during playback.  Have spent more hours than I care to 
say trying to fix this, only to downgrade again.


vdr-1.6.0 and xine-0.8.0 work just fine for me!!


Simon
- Original Message - 
From: "Gerald Dachs" 

To: 
Sent: Thursday, November 26, 2009 8:57 AM
Subject: Re: [vdr] vdpau setup steps for vdr client



Am Wed, 25 Nov 2009 21:50:16 +0200 (EET)
schrieb Mika Laitio :


I just bought a zotac ion motherboard and plan to harness it in the
weekend as a ultimate super master dream vdr client for my 19"
monitor :-)

Sofar I have used to run vdr-xineliboutput in my clients and would
like to do that also with this machine if possible. Currently my
server runs vdr 1.6 but I plan to update that also to 1.7.10.


You could give this a try:
https://launchpad.net/~the-vdr-team/+archive/vdr-ubuntu-karmic

Gerald

___
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