Re: [vdr] vdr error on turksat 42

[Halim Sahin]

Hi,
On Mi, Jan 24, 2007 at 07:44:38 +0100, Halim Sahin wrote:
> Hi,
> On Mi, Jan 24, 2007 at 08:28:53 +0200, Lauri Tischler wrote:
> > Nothing is wrong, VDR works correctly, changes channel names
> > to correct broadcasted name.
> 
> That could not be the problem because vdr changes the name of the
> first channel bak to the right vallues after switching back to it.
> While watching the second one the channellist shows wrong vallues for
> ATV. When I switch back to it vdr correct this. Thanks Halim

I found more channels in my list with the same problem.
Perhaps they are created with wrong values that causes vdr to change 
thair names
Oh yes I know the option menu->settings->update channels
But I want tell you again that the channelnames were not broadcasted 
wrong.
Channel one shows its right name until the user switches to another 
channel.
The channellist shows now wrong names for channel 1.
If I switch back to it vdr corrects these wrong names.

Best regards
Halim





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

Re: [vdr] frontend tuning timeouts break DD AC3 stream

[Torgeir Veimo]

On 24 Jan 2007, at 22:01, Thomas Bartschies wrote:


Am Mittwoch, 24. Januar 2007 22:38 schrieb Klaus Schmidinger:

Thomas Bartschies wrote:

Hi,


[snip]

I have a three FF card system. Why does vdr use the Primary Card for
scans anyway? Shouldn't all of this occur on a non-primary card  
all of


If VDR is currently replaying (or receiving in transfer mode from
an other card) the primary card is available for recording as well as
EPG scanning.



I forget to mention, that the problem only occurs when replaying a  
recording.
Watching LiveTV by using LiveAC3 and even AC3 in transfer mode on  
encrypted
channels works perfectly. So if the problem would be in the FW or  
driver, the

problem would occur in LiveTV too, wouldn't it?


I see similar problems here, caused by the DVB driver using too much  
kernel time when a card cannot tune a station.


My primary DVB device can tune all channels. My secondary cannot tune  
all, for some unknown reason. Thus I have set up the secondary DVB  
device as the main device used for normal TV viewing, since I don't  
want VDR to try to tune to get EPG data on that card. But when  
playing recordings, VDR uses the first available card, so the problem  
reappear.


There is a similar problem, if I try to record a channel on a card  
that cannot tune to the channel, VDR segfaults.


--
Torgeir Veimo
[EMAIL PROTECTED]




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

Re: [vdr] frontend tuning timeouts break DD AC3 stream

[Thomas Bartschies]

Am Mittwoch, 24. Januar 2007 22:38 schrieb Klaus Schmidinger:
> Thomas Bartschies wrote:
> > Hi,
> >
[snip]
> > I have a three FF card system. Why does vdr use the Primary Card for
> > scans anyway? Shouldn't all of this occur on a non-primary card all of
>
> If VDR is currently replaying (or receiving in transfer mode from
> an other card) the primary card is available for recording as well as
> EPG scanning.
>

I forget to mention, that the problem only occurs when replaying a recording.
Watching LiveTV by using LiveAC3 and even AC3 in transfer mode on encrypted
channels works perfectly. So if the problem would be in the FW or driver, the
problem would occur in LiveTV too, wouldn't it?

Is it possible that there are thread locking issues between the tuner and the
replay thread, when a timeout occurs?

I had a nasty NTPL thread locking problem with the tuner routine for a long
time, until a patch on this mailing list fixed it. It was called 
dvbtuner-one-mutex.diff and was applied by you somewhere around vdr 1.3.28.
Without this vdr doesn't even start.

> > the time? How can I force vdr to not use the primary device for PID,EPG
> > and all other scans? At least for further testing.
>
> Edit cEITScanner::Process() so that it doesn't use the primary device.

How? Little hlp pls. ;-)

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

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

Re: [vdr] frontend tuning timeouts break DD AC3 stream

[Klaus Schmidinger]

Thomas Bartschies wrote:
> Hi,
> 
> I'm experiencing the usual DD A3 stream breaks here. Now I have discovered
> that the epg scan seems to trigger them, by tuning to some channels.
> 
> vdr logs frontend tuning timeouts synchronously to the stream breaks my
> AV Receiver displays. They can only be caused by a background job like
> the epg scan. Also the timeouts occur on the primary card, which seem
> to be sometimes used to make scans.
> 
> I'm not sure if the tuning timeouts were caused because the channels are
> encrypted, or by invalid data in the channels.conf. But that should have no
> meaning here.
> 
> The timeouts can be caused by the firmware or driver, or in vdr by tuner
> thread locking issues. I need help to sort this out.
> 
> I have a three FF card system. Why does vdr use the Primary Card for
> scans anyway? Shouldn't all of this occur on a non-primary card all of

If VDR is currently replaying (or receiving in transfer mode from
an other card) the primary card is available for recording as well as
EPG scanning.

> the time? How can I force vdr to not use the primary device for PID,EPG
> and all other scans? At least for further testing.

Edit cEITScanner::Process() so that it doesn't use the primary device.

Klaus

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

[vdr] frontend tuning timeouts break DD AC3 stream

[Thomas Bartschies]

Hi,

I'm experiencing the usual DD A3 stream breaks here. Now I have discovered
that the epg scan seems to trigger them, by tuning to some channels.

vdr logs frontend tuning timeouts synchronously to the stream breaks my
AV Receiver displays. They can only be caused by a background job like
the epg scan. Also the timeouts occur on the primary card, which seem
to be sometimes used to make scans.

I'm not sure if the tuning timeouts were caused because the channels are
encrypted, or by invalid data in the channels.conf. But that should have no
meaning here.

The timeouts can be caused by the firmware or driver, or in vdr by tuner
thread locking issues. I need help to sort this out.

I have a three FF card system. Why does vdr use the Primary Card for
scans anyway? Shouldn't all of this occur on a non-primary card all of
the time? How can I force vdr to not use the primary device for PID,EPG
and all other scans? At least for further testing.

Best Regards,
Thomas

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

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Marko Mäkelä]

On Wed, Jan 24, 2007 at 06:49:10PM +0100, Udo Richter wrote:
> Well, strange things happen. I've had such a side effect on my runvdr 
> extreme with a closed stdout, see here: (German)
> http://www.vdr-portal.de/board/thread.php?postid=542948#post542948
> 
> In this case, printf on kanotix complained heavily on a closed stdout, 
> and the only workaround was to replace >&- with the traditional >/dev/null.

Closing stdout is a different matter.  But I agree with you, it may be
not a wise idea to close stdin either.  The workaround  >Are you planning to maintain the 1.4 branch of the patch?  If yes
> >(and I hope so), can plugins use some #ifdef to see if
> >Shutdown.IsUserInactive() is available?
> 
> For now I'll maintain it, currently the differences are only minor. 
> Adding some #ifdef detection is a good idea, I'll add that for the next 
> 1.4 patch.

Thank you!  I plan to keep using 1.4 at least until 1.5 supports
DVB subtitles (which I hope it will support at some point) or UTF-8.

Marko

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

[vdr] DVB-S & Analog combo card?

[Czakó Krisztián]

Hello,

Is there any DVB-Sat and analog combo card that is supported by the 
current linux drivers and VDR? I'm interested in all types (budget or 
full). I've found only DBV-T&Analog ones :(


If there isn't, which hw encoder capable analog card is recommended for 
use with VDR?


Regards,
Slapic

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

Re: [vdr] FF card A/V sync - in progress?

[Pasi Juppo]

Hi,

Unfortunately I deleted the episode immediately after I had watched it
(I seldom save any episodes anyway). But if this happens again I'll make
a clip for futher evaluation.

I don't recall having ever problems with audio sync in live TV. I'm
using TT FF v1.5 (iirc) and also TT1500 budget.

Br, Pasi


Morfsta wrote:
> Hi Pasi,
>  
> Perhaps you could cut the clip and send it to Oliver and Werner for
> further testing and debugging?
>  
> I do still have sync problems too with live TV and freeview, but it is
> not as bad as it was. I don't understand though why no-one else seems to
> have sync problems with live TV, so I have rolled back to an older
> driver for my DVB-T card (TDA-100045) as I changed a year ago and that
> might have been when it started, but I changed the AV7110 firmware at
> the same time. I'll see if it improves things.
>  
> Regards,
>  
> Morfsta
>  
> On 1/23/07, *Pasi Juppo* <[EMAIL PROTECTED] >
> wrote:
> 
> Pasi Juppo wrote:
> > Anyway, I can report also that A/V sync problem does not seem to be
> > bothering anymore. Excellent work!
> 
> I was a bit too hasty. Sync got lost once while watching Pako (Prison
> Break). However, it was nicer than earlier. Sync was out of sync but the
> video and audio played nicely - just out of sync. Previously audio was
> making cracking noise time to time.
> 
> Br, Pasi
> 
> ___
> vdr mailing list
> vdr@linuxtv.org 
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
> 
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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

Re: [vdr] vdr error on turksat 42

[Halim Sahin]

Hi,
On Mi, Jan 24, 2007 at 08:28:53 +0200, Lauri Tischler wrote:
> Nothing is wrong, VDR works correctly, changes channel names
> to correct broadcasted name.

That could not be the problem because vdr changes
the name of the first channel bak to the right vallues after switching 
back to it.
While watching the second one the channellist shows wrong vallues for 
ATV.
When I switch back to it vdr correct this.
Thanks
Halim


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

Re: [vdr] vdr error on turksat 42

[Lauri Tischler]

Halim Sahin wrote:

Hello,

In my channels.conf there are the channels:

atv;Service Provider:12633:v:S42.0E:4800:308+8179:256=eng:0:0:1:1:1:0
SAMANYOLU TV;STV:11951:v:S42.0E:8800:300:301=tur:0:0:1:1:48:0

Vdr start on ATV.
After switching to the second channel, vdr changes the name and 
providername of the first one. llike this:


SAMANYOLU TV;STV:12633:v:S42.0E:4800:308+8179:256=eng:0:0:1:1:1:0
SAMANYOLU TV;STV:11951:v:S42.0E:8800:300:301=tur:0:0:1:1:48:0
Whats wrong there?


Nothing is wrong, VDR works correctly, changes channel names
to correct broadcasted name.
If you dont want that, change 'Setup -DVB - Update channels:'
to suitable setting, maybe 'pids only' of 'no'


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

More infos Re: [vdr] vdr error on turksat 42

[Halim Sahin]

Hi,

My vdr is vdr-1.4.4
menu->settings->dvb
Update channels: add new channels
Thanks
Halim

-- 
Halim Sahin
E-Mail: 
halim.sahin (at) t-online.de

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

[vdr] vdr error on turksat 42

[Halim Sahin]

Hello,

In my channels.conf there are the channels:

atv;Service Provider:12633:v:S42.0E:4800:308+8179:256=eng:0:0:1:1:1:0
SAMANYOLU TV;STV:11951:v:S42.0E:8800:300:301=tur:0:0:1:1:48:0

Vdr start on ATV.
After switching to the second channel, vdr changes the name and 
providername of the first one. llike this:

SAMANYOLU TV;STV:12633:v:S42.0E:4800:308+8179:256=eng:0:0:1:1:1:0
SAMANYOLU TV;STV:11951:v:S42.0E:8800:300:301=tur:0:0:1:1:48:0
Whats wrong there?
Halim

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

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Udo Richter]

Marko Mäkelä wrote:

On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote:
Since the shutdown script runs in the background, the stdin could 
probably be closed. After all, VDR should continue to 'own' stdin, and 
running in the background would probably cause a conflict. However, 
running the script with a closed file handle may cause other side effects.


I can't think of any side effect.  The shutdown script is not supposed
to be interactive, and system tools generally do not read stdin.


Well, strange things happen. I've had such a side effect on my runvdr 
extreme with a closed stdout, see here: (German)

http://www.vdr-portal.de/board/thread.php?postid=542948#post542948

In this case, printf on kanotix complained heavily on a closed stdout, 
and the only workaround was to replace >&- with the traditional >/dev/null.



Are you planning to maintain the 1.4 branch of the patch?  If yes
(and I hope so), can plugins use some #ifdef to see if
Shutdown.IsUserInactive() is available?


For now I'll maintain it, currently the differences are only minor. 
Adding some #ifdef detection is a good idea, I'll add that for the next 
1.4 patch.


Cheers,

Udo


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

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Marko Mäkelä]

On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote:
> Since the shutdown script runs in the background, the stdin could 
> probably be closed. After all, VDR should continue to 'own' stdin, and 
> running in the background would probably cause a conflict. However, 
> running the script with a closed file handle may cause other side effects.

I can't think of any side effect.  The shutdown script is not supposed
to be interactive, and system tools generally do not read stdin.

There are two reasons why my runvdr script closes stdin and redirects
stdout and stderr to a file.  First, scrolling console output on the bitmap
framebuffer could interfere with softdevice-dfb or slow down the playback.
Second, I may occasionally launch the runvdr script via an ssh session,
and the ssh session would refuse to close if stdin, stdout, or stderr are
being used after exiting the shell.

I guess I could work around this bug by leaving file descriptor 0 open
before starting vdr, e.g., by replacing the <&- with http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] FF card A/V sync - in progress?

[Morfsta]

Hi Pasi,

Perhaps you could cut the clip and send it to Oliver and Werner for further
testing and debugging?

I do still have sync problems too with live TV and freeview, but it is not
as bad as it was. I don't understand though why no-one else seems to have
sync problems with live TV, so I have rolled back to an older driver for my
DVB-T card (TDA-100045) as I changed a year ago and that might have been
when it started, but I changed the AV7110 firmware at the same time. I'll
see if it improves things.

Regards,

Morfsta

On 1/23/07, Pasi Juppo <[EMAIL PROTECTED]> wrote:


Pasi Juppo wrote:
> Anyway, I can report also that A/V sync problem does not seem to be
> bothering anymore. Excellent work!

I was a bit too hasty. Sync got lost once while watching Pako (Prison
Break). However, it was nicer than earlier. Sync was out of sync but the
video and audio played nicely - just out of sync. Previously audio was
making cracking noise time to time.

Br, Pasi

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

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

Re: [vdr] OSD-Resolution

[Rene Hertell]

Petri Helin wrote:

> The patches are here: http://www.netholic.com/viewtopic.php?t=1622
> Unfortunately, if you do not speak Finnish, it might a bit hard to
> follow that thread

Kiitos! Thanks!

Finnish is no problem for me :-)

Terveisin,

René

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

Re: [vdr] FF card A/V sync - in progress?

[Tero Siironen]

2007/1/23, Kartsa <[EMAIL PROTECTED]>:

Could this be related to some sw or hw issue? I have had this new fw for
a few days now and about 20+ succesfull recordings and no failures.

I've got vdr 1.4.4, burn 0.0.009, subtitles 0.4.0, femon 1.1.0, mplayer
0.9.15 and vompserver 0.2.5.
And on the hw side AMD Sempron 3000+, 512MB, TT DVB-C FF 2.1, DVB-C
budget, FC6, kernel  2.6.18-1.2849.


Well, like I said I cannot confirm that this was because of the new
firmware, and I've made two successful timer recordings on Sunday. But
on the other hand this was the very first time that recording failed
(excluding human errors) with my new setup, built in last July and
about 1-5 recordings every week.

I now updated vdr and plugins and added more error recovery to it. So we'll see.


--
Tero

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