Re: [vdr] will VDR run on this?

[Timothy D. Lenz]

broadcom? yea right, someone will likely have to be willing to buy 
50,000 before they will even start producing them and then you'll need 
to be willing to buy 10-20,000 unless someone like digi-key decides to 
stock it. They made a cool tuner chip that handled most if not all 
current sat formats, but it never went to production because no one 
would commit to a insane quanity.


On 8/1/2011 1:19 AM, Luca Olivetti wrote:

Al 01/08/11 10:04, En/na Steffen Barszus ha escrit:

2011/8/1 Gerald Dachs:

http://www.geek.com/articles/chips/raspberry-pi-25-pc-goes-into-alpha-production-20110728/

Any thoughts?


VDR runs just fine on a seagate dockstar, so I see no reason why it
shouldn't run on this device, but I don't believe that it has enough power
show the TV signal via hdmi.


Not so sure, depending on driver availability:
http://www.mikrocontroller.net/topic/224132#2254607

OpenGL ES 2.0
1080p30 H.264 high-profile decode

Well lets see, when it apears, if it will be available to normal
people AND if the required driver will be there too.


It's broadcom, so I doubt it: the wolf may lose his teeth but never his nature.
At most (if anything) we'll get a binary blob tied to a specific kernel version
with no possible upgrade path.

Bye


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

Re: [vdr] howto ignore lines in channels.conf

[Timothy D. Lenz]

You could change the line to  a lable by starting it with ": ". If I 
understand it correctly, using a space after : instead of @ and it 
becomes a label for the channels after. A way to group them sort of. You 
can then using it as a quick jump to the channel that follows, but it 
should be skiped when just surfing and it shouldn't try to save EPG data 
for it.


On 1/15/2012 3:56 AM, Eric Valette wrote:

On 15/01/2012 11:26, Klaus Schmidinger wrote:


What charakter can i add in front of a line to let the line be ignored?


There is no comment character in channels.conf, because
VDR writes this file, and thus any comments would be lost.


IMHO This is not a sufficient answer: it could skip the line with a
comment character when rewriting (and unless it changed, it may not
rewrite it is no PMT/pid scanning is requested)

--eric





___
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] IS there a working UPnP-AV/DLNA support for VDR?

[Timothy D. Lenz]

I'm interested in this also, but we have 2 Sony Bravias. Hacking the Tv 
not an option.  I do know that on ours, for youtube, you can do searches 
and stuff using an on screen alphabet that follows the letter to number 
grouping you see on phones. So it does have a way to enter stuff.


On 2/10/2012 1:43 PM, Luca Olivetti wrote:

Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit:

I suppose you could use mediatomb with vdrnfofs to share your recordings.


Or hack the TV to simply nfs mount the directory with the recordings


Bye


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

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

[Timothy D. Lenz]

On 3/2/2012 11:06 AM, VDR User wrote:

On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton  wrote:

Signal the server to start recording. But then the client has to be able
to match up its buffer with what the server has recorded after the
buffer filled and let the server know when the temp recording is no
longer needed. Complicated.


Maybe something like this would work...

User can define how much of his ram he wants used for buffering. VDR
uses x% of this for constant buffering. The remainder is only used
when pause/rewind has been pressed. When the remainder is filled, the
entire buffer is dumped to disk as a temp recording, which continued
to be recorded until a) live view has been resumed for X secs, or b)
until the show ends. The temp recording is then purged after a user
defined X minutes (or never if 0) of it's last modified timestamp.

If live buffering is to be added, it should have some flexibility, but
it still doesn't need to be overly complicated. Whatever the actual
live buffer behavior, I believe a ram-based solution is the best
choice for a number of reasons.


Have the server record everything it plays and not bother with buffering
in the client. I don't think most people want VDR to work that way
because of extra load on the hard drive.


HELL NO! I will not use software that forces my harddrive(s) into a
constant write state 24/7. I don't want the extra wear. I don't want
the extra heat. I don't want the extra power consumption. And I'm
certainly not alone.

I agree, this is what MythTV does and why I never tried to fully install 
it. I started to once to try it out, but I just didn't like the need for 
continous recording.  Would be ok with sold state drives that don't ware 
out with use like the current ones do. But even they are too costly for 
me to even look at.


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

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

[Timothy D. Lenz]

On 3/3/2012 4:48 AM, Klaus Schmidinger wrote:

On 02.03.2012 18:13, Udo Richter wrote:

Am 02.03.2012 11:06, schrieb Klaus Schmidinger:

On 29.02.2012 21:33, Udo Richter wrote:

Roughly, the callback should be at the places where these two get
called:

DELETENULL(liveSubtitle);
DELETENULL(dvbSubtitleConverter);

(Thats how VDR's own receivers get out of way.)


There are two places in GetDevice() where
cStatus::MsgChannelSwitch(this, 0)
is called, but they are both *after* the final call to GetDevice().
And there is this comment

// only report status if we are actually going to switch the channel

which refers to a change that was made in version 1.1.10:

- Only calling cStatus::MsgChannelSwitch() if a channel is actually
going to
be switched or has actually been switched successfully (thanks to Stefan
Huelswitt).



Good point. What if VDR wants to switch, but fails. Is it possible that
the channel change still fails after deleting liveSubtitle and
dvbSubtitleConverter? How does VDR itself handle this? Need to
investigate this.


If switching to a certain channel fails, VDR will notice that the
primary device no longer HasProgramme() and will try to switch to
a different channel.


If a call to MsgChannelSwitch(this, 0) was done on channel change, we
have to make sure that the corresponding call for the new channel does
happen, or - worst case - there's a call for the old channel again.



What I really see as a problem here now is that the first call to
GetDevice() may call a device's DetachAllReceivers() and the second
GetDevice() call may then decide to actually use a different device.
I'm currently considering giving GetDevice() another parameter:

static cDevice *GetDevice(const cChannel *Channel, int Priority, bool
LiveView, bool Query = false);


+1, as I know that something like this was on some wish lists for some
time. ;)


I'll release version 1.7.25 later today, so that all these changes can
be reviewed and tested.

Klaus



A problem I have run into before is not that a channel is down, though 
that also happens, but that a tuner is down. I've had tuner crashes, but 
vdr just stayed with that tuner/chanel and recorded nothing. I currently 
have 5 ATA tuners. 2 Dual tuner cards and a single.


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

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

[Timothy D. Lenz]

No, but I have the auto shutdown thing turned off because when signal is 
bad on 1 channel, it would disrupt everything with frequent restarts and 
as I recall, it often didn't restart. Might have been xine or something 
that stopped with the restart, I don't recall. Plus, restarting VDR in 
this case wouldn't fix the problem because it's a hardware crash that 
requires the drivers be restarted. One card finally died and had to be 
replaced which helped, but I know I have to leave power save off on 
those cards because the tuners get flaky when it's used and seems to be 
what killed the card. Poor craftsmanship.


On 3/4/2012 2:51 PM, Klaus Schmidinger wrote:

On 04.03.2012 19:04, Timothy D. Lenz wrote:

...
A problem I have run into before is not that a channel is down, though
that also happens, but that a tuner is down. I've had tuner crashes,
but vdr just stayed with that tuner/chanel and recorded nothing. I
currently have 5 ATA tuners. 2 Dual tuner cards and a single.


Didn't VDR report a "video data stream broken" and perform a restart?

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] [ANNOUNCE] VDR developer version 1.7.24

[Timothy D. Lenz]

On 3/5/2012 2:52 AM, Gero wrote:

On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:

On 05.03.2012 04:47, Gero wrote:

On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:

On 04.03.2012 19:04, Timothy D. Lenz wrote:

...
A problem I have run into before is not that a channel is down, though
that also happens, but that a tuner is down. I've had tuner crashes,
but vdr just stayed with that tuner/chanel and recorded nothing. I
currently have 5 ATA tuners. 2 Dual tuner cards and a single.


Didn't VDR report a "video data stream broken" and perform a restart?


That problem coincides with my problem of recordings with length 0 and
filesize of few megabytes. Didn't know that it comes from a crashed
tuner.

If I remember right, there was no "video data stream broken" message and
after enabling the automatic shutdown I realized, that the vdr waits
until no recording is active before initiating the restart.

So the automatic restart did not really help anything, especially in
environments, where multiple parallel recordings are most probably to
happen.


It doesn't matter whether there is only one or multiple recordings.
Whenever a "video data stream broken" occurs, VDR performs an immediate
"emergency exit" (unless you turned that off, but then you're on
your own).


That might be true.

When I first reported recordings with length 0, the emergency exit was
disabled. That time I had log-entries with "video data stream broken".
According your advice, I enabled it, but since then I had no more log-entries
with "video data stream broken", but had recordings with length 0

So there might be other reasons that stop vdr from recording without any
notice / log entry


So if a tuner doesn't deliver any more data, VDR restarts
and reloads the driver (provided you use a properly set up "runvdr"
script).


Hm, I gues my runvdr might be ok, since my backend does timer-controlled
wakeup and shuts down in idle state.


kind regards

Gero





Restarting when you have more then one recording screws up the working 
ones. The local broadcasters are morons about digital broadcast. Even 
with a good strong signal you can have broken up video which would 
trigger the restart making things even worse.


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

Re: [vdr] same channel on different hardware

[Timothy D. Lenz]

On 4/25/2012 2:46 AM, syrius...@no-log.org wrote:

Marx  writes:


Hello
Let's say I have same channel available from DVB-S and DVB-T. Is it
possible to tell VDR that those channels are the same and can be
treated the same as on dual head DVB-S devices?
So It would share EPG and would be used for recording if needed.
There probably would be need to do some prioritizing which device
would be used as first choice.


Hi,

No at all, this has been on the wish list for a long time though :-)
maybe for vdr 2.1 :)

As far as i know, there's no official ticket/issue/wishlist tracker
or development repository for main vdr.
If you want to have a look at the wishes and patches you'll have to
dig the mailing list archives.



There is a plugin called EPGSync that will copy guide date from one 
channel to another where it is missing based on channel names. It has 
some drawbacks, but does work. I pull guide date of Dishnets sat for 
local channels because they go out 9 days and the yocals that run the 
local stations are sometimes doing good to get a few hours out. Once 
they do send out data even if it's just the name but no discription, all 
the guide data for the channel/time is replaced with the new data.


Epgsearch will then set up timers when the dishnet data comes in and 
because it is the same on both channels, it would set up timers for 
both, but as the dishnet channels are scrambled, I just limit the search 
to the ota channels.


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

[vdr] ATSC scanning support request

[Timothy D. Lenz]

ATSC is the standard for OTA broadcast in the US now. It would be nice 
if support could be built into vdr now. The plugin for getting eit data 
and scanning for channels hasn't been updated in 2 years. It still has 
problems. on my x64 system, it seg faults most of the time when trying 
to scan for channels. It's more of a fluke that when it does work. And 
boradcasters don't follow the standards or something because I often 
don't have guide data when a 60$ converter box is able to find guide data.


It would be nice to have its functions moved to VDR and then just dump 
the plugin. It served it's purpose when ATSC was just starting to be 
used, but it's time to build it in instead of it being an after thought.


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

Re: [vdr] ATSC scanning support request

[Timothy D. Lenz]

The problem here in the US is, DVB is not a standard for anything.

On 8/25/2012 2:42 AM, Klaus Schmidinger wrote:


I don't think that problems would be fixed any better if this were
part of the official VDR code. If the original author no longer maintains
the code, somebody else should take over and fix it.
VDR is mainly written for the *DVB* standard. Anything else should be
external.

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] ATSC scanning support request

[Timothy D. Lenz]

The crashing problem would be better address by making it part of VDR. I 
am trying to make scripts to use Schedules Direct because even if VDR 
was picking up what the broadcasters send, the broadcasters themselves 
are unreliable and half assed at sending eit. But if the seg fault when 
trying to scan for new channels where fixed, that would help.


On 8/25/2012 2:42 AM, Klaus Schmidinger wrote:

On 25.08.2012 04:04, Timothy D. Lenz wrote:

ATSC is the standard for OTA broadcast in the US now. It would be nice
if support could be built into vdr now. The plugin for getting eit
data and scanning for channels hasn't been updated in 2 years. It
still has problems. on my x64 system, it seg faults most of the time
when trying to scan for
channels. It's more of a fluke that when it does work. And
boradcasters don't follow the standards or something because I often
don't have guide data when a 60$ converter box is able to find guide
data.

It would be nice to have its functions moved to VDR and then just dump
the plugin. It served it's purpose when ATSC was just starting to be
used, but it's time to build it in instead of it being an after thought.


I don't think that problems would be fixed any better if this were
part of the official VDR code. If the original author no longer maintains
the code, somebody else should take over and fix it.
VDR is mainly written for the *DVB* standard. Anything else should be
external.

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] ATSC scanning support request

[Timothy D. Lenz]

http://www.fepg.org/

I suspect he ether got too busy to work on it anymore or just got tired 
of of it. He put out several nice plugins in a short time back when the 
US switched to ATSC.


On 8/28/2012 8:05 AM, Dominic Evans wrote:

On 25 August 2012 20:54, Timothy D. Lenz  wrote:

The problem here in the US is, DVB is not a standard for anything.


I'm guessing Klaus' problem here is that he doesn't live in the US so
can't access ATSC broadcasts for testing, so it doesn't really make
sense for him to attempt to maintain it in VDR core :)

Where is the current home for the ATSC plugin and who is/was the
original maintainer? Ideally it needs a US-based maintainer, but
(failing that) it should at least be migrated to somewhere more public
(e.g., github or vdr-developers) so that bugs/issues can be tracked.

___
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] ATSC scanning support request

[Timothy D. Lenz]

Yes, and there are programs that can capture part of a stream to a file 
to examine. So you don't need access to the stream to see where the 
broadcasters are failing to follow the FCC set standards. I think 
Dvbsnoop is one and I have compiled, though I only used it once or twice 
several years ago.


I think the plugin dev once said it is likely that the reason I don't 
get data sometimes is because there is some flag to set that there is 
data and they don't set it. The converter boxes and TV's ignore the flag 
and go look for the data.


On 8/28/2012 9:53 AM, VDR User wrote:

On Tue, Aug 28, 2012 at 8:05 AM, Dominic Evans  wrote:

On 25 August 2012 20:54, Timothy D. Lenz  wrote:

The problem here in the US is, DVB is not a standard for anything.


I'm guessing Klaus' problem here is that he doesn't live in the US so
can't access ATSC broadcasts for testing, so it doesn't really make
sense for him to attempt to maintain it in VDR core :)

Where is the current home for the ATSC plugin and who is/was the
original maintainer? Ideally it needs a US-based maintainer, but
(failing that) it should at least be migrated to somewhere more public
(e.g., github or vdr-developers) so that bugs/issues can be tracked.


It would be nice if it were moved to vdr-developers. I don't think the
author would even have a problem with that. The real drawback for NA
is that while there are plenty of users, there's practically no coders
here. The ones I know have either left VDR, or dvb altogether.
Thankfully there has been some EU coders willing to throw us a bone
and help out occasionally. With their help, and Klaus, NA VDR is far
less painful today that in the past. :)

___
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] ATSC scanning support request

[Timothy D. Lenz]

I don't mess with this enough to remember the steps for making the 
dumps, but making it crash is as easy as telling it to scan for 
channels. So if you want to put up the steps to get the data... :)


I'm using Debian x64 and I use putty/winscp to work with it.

On 8/28/2012 1:11 PM, Dominic Evans wrote:

On 28 Aug 2012, at 20:58, "Timothy D. Lenz"  wrote:


The crashing problem would be better address by making it part of VDR. I am 
trying to make scripts to use Schedules Direct because even if VDR was picking 
up what the broadcasters send, the broadcasters themselves are unreliable and 
half assed at sending eit. But if the seg fault when trying to scan for new 
channels where fixed, that would help.


Do you have a core file from when it segfaulted in the past? Or, can
you reproduce it and capture one?

___
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] ATSC scanning support request

[Timothy D. Lenz]

Just did a crash to grab what is in the logs:

/var/log/
syslog:
Aug 29 13:57:01 x64VDR vdr: [9106] ATSC Scanner thread started 
(pid=20976, tid=9106)
Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 
7f9ca8000108 ip 7f9ca8000108 sp 7f9c9dc9cbc8 error 15


messages:
Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 
7f9ca8000108 ip 7f9ca8000108 sp 7f9c9dc9cbc8 error 15


kern.log
Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 
7f9ca8000108 ip 7f9ca8000108 sp 7f9c9dc9cbc8 error 15


On the tv it just locks up. have to restart vdr

On 8/28/2012 1:11 PM, Dominic Evans wrote:

On 28 Aug 2012, at 20:58, "Timothy D. Lenz"  wrote:


The crashing problem would be better address by making it part of VDR. I am 
trying to make scripts to use Schedules Direct because even if VDR was picking 
up what the broadcasters send, the broadcasters themselves are unreliable and 
half assed at sending eit. But if the seg fault when trying to scan for new 
channels where fixed, that would help.


Do you have a core file from when it segfaulted in the past? Or, can
you reproduce it and capture one?

___
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] ATSC scanning support request

[Timothy D. Lenz]

I build from the hg source.

On 9/10/2012 9:20 AM, Dominic Evans wrote:

Hi Timothy,

On 29 August 2012 22:01, Timothy D. Lenz  wrote:

Just did a crash to grab what is in the logs:

/var/log/
syslog:
Aug 29 13:57:01 x64VDR vdr: [9106] ATSC Scanner thread started (pid=20976,
tid=9106)
Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 7f9ca8000108
ip 7f9ca8000108 sp 7f9c9dc9cbc8 error 15

messages:
Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 7f9ca8000108
ip 7f9ca8000108 sp 7f9c9dc9cbc8 error 15

kern.log
Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 7f9ca8000108
ip 7f9ca8000108 sp 7f9c9dc9cbc8 error 15

On the tv it just locks up. have to restart vdr


There's not really much to see from this, apart from showing us that
it is the ATSC Scanner code itself causing the segfault :)

You'll need to recompile the plugin yourself to preserve debug symbols
(any debian packaged version will likely be stripped of symbols) and
then copy it into /var/lib/vdr/plugins (or wherever your vdr is
configured to store plugins)

Then you'll need to make sure core files are generated, e.g., by
adding `ulimit -c unlimited` before the call to /usr/bin/vdr in
/usr/sbin/runvdr (again assuming you're using debian packages).

Then you should get core files generated if a segfault occurs.

___
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] polarization character case in channels.conf

[Timothy D. Lenz]

I have used upper and lower case to denote for different sources in the 
past in diseqc.conf and it worked. Case needs to, or needed to in the 
past, match.


On 11/7/2012 9:12 AM, Mike Hay wrote:

Well, there is a toupper() in cDvbTransponderParameters::Parse(), so
I would expect that all characters can be given in either upper- or
lowercase.

Are you sure the case was the problem?

Klaus


I'm pretty sure it is the case as I have tested the following two strings with 
no other changes and get different results.

ITV1 
London;BSkyB:10758:VC56M2O0S0:S28.2E:22000:3328=2:3329=eng@4,3330=NAR@4:2326;2327=eng:0:10060:2:2044:0
 # This works
ITV1 
London;BSkyB:10758:vC56M2O0S0:S28.2E:22000:3328=2:3329=eng@4,3330=NAR@4:2326;2327=eng:0:10060:2:2044:0
 # This doesn't

Mike



___
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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Timothy D. Lenz]

I glanced at these boards because at one time I wanted to replace my old 
nexus card and I only want to use multi-tunner cards from now on. I 
could not afford any upgrades now though:(


But one thing I noticed is, they only support 8PASK modulation and not 
the others, 16/32. While they may not be used much now, if usage does 
pick up, then these cards are useless and the money wasted. If I had the 
money to spend on new tuner cards, I would hold out for one that covered 
the possible modulations better.


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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Timothy D. Lenz]

I prefer to keep files for a given program together in that programs 
tree. Not scatter all over the computer like ms. The only thing for vdr 
I move is the recordings because of the space required. All 
settings/config files for vdr belong in the vdr directory tree.


On 12/25/2012 1:07 PM, Klaus Schmidinger wrote:

On 25.12.2012 20:47, Reinhard Nissl wrote:

Hi,

as mentioned in the VDR-1.7.34 announcement, Make.config is now gone
for plugins.

Make.config gave me the opportunity to control features or behavior of
plugins and VDR at a central location without having the need to
adjust each plugin's Makefile. For example, while developing vdr-xine,
I could keep vdr-xine's Makefile in a distributable state and still
control to enable some
features I'd like to use in my local configuration. And when upgrading
some other plugins at bugfix level (i. e. there are usually no new
features and hence the config variables can stay the same), there was
no need to adjust the Makefile due to the config entries in Make.config.

Here is an excerpt of my Make.config for an example of the above
mentioned configuration settings:


#xine
#VDR_XINE_VDR_HAS_TRUECOLOR_OSD = 1
VDR_XINE_SET_VIDEO_WINDOW = 1
VDR_XINE_VERIFY_BITMAP_DIRTY = 0

#burn
DVDDEV=/dev/hdd
ISODIR=/video

#vdr
BIDI=1
VFAT=1
REMOTE=LIRC
LIRC_PUSHFREQ=64 # 1/s
LIRC_REPEATDELAY=250 # ms
LIRC_REPEATFREQ=32 # 1/s
#LIRC_REPEATTIMEOUT=500 # ms
#LIRC_RECONNECTDELAY=3000 # ms
LIRC_PRIORITYBOOST=1

#muggle
HAVE_ONLY_SERVER=1


As you can see, there is nothing like changing compiler or linker
settings -- for that stuff, I really appreciate the way it is done now.

In a private discussion with kls, he asked me to talk to other plugin
developers too (so here we are) about that issue, so that any solution
in that regard will be of broad agreement by all developers.

To conclude:
1.) there is a need for a common make configuration file for both VDR
and plugins.


No, only for *plugins*!
VDR itself will have nothing to do with this file!


2.) the file should be included in VDR's Makefile after including
Make.config (maybe that idea should be dropped in favor of 5.a) as any
VDR related option can be put into Make.config anyway).


See 1.).


3.) the file should be included into plugin Makefiles after having set
PLUGIN and VERSION to be able to have some plugin-/version-dependent
configuration.


Agreed.


4.) the file is optional -- maybe a template file like
Make.config.template could indicate that there is something available
for tuning.

5.) how do we name the file?
5.a) plugins.conf (doesn't fit perfectly for 2., to be a common file
for VDR too)


No need, see 1.).


5.b) Make.common
5.c) local.conf
5.d) Make.config.local

6.) where do we put the file?
6.a) kls suggested /etc/vdr at a random shot
6.b) I would like to put it next to Make.config
6.c) use pkg-config to determine path (defaults to VDRDIR)


Can't we just agree on a fixed place for this file?
Does it really have to be somewhere else on every system?

I suggest to put the lines

PLGCFG ?= /etc/vdr/plugins.conf
-include $(PLGCFG)

into each plugin's Makefile and that's it.

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] Rotor plugin source?

[Timothy D. Lenz]

I haven't tried the patch, just the plugin. The plugin had some nice 
features that where handy. My rotor isn't even active now. Needs to be 
realigned after replacing a limit switch and I never have much secess 
aligning it. That and there is so little FTA in the US on small dish. 
Hardly worth the effort.


On 2/12/2013 11:29 PM, Teemu Suikki wrote:

Hi,

thanks alot! This works very well!

Also I think my "section handler delay" patch is not necessary with this
gotoxx patch.. At least my delay message appears much later now, so the
delay is already in the gotox handling.

This GotoX patch is so cleanly integrated to VDR, I think it should be
included in the official release? I think all current diseqc motors have
gotox functionality, so plugins like rotor(ng) are really unnecessary if
gotox works.

--
Teemu

2013/2/12 Ales Jurik mailto:aju...@quick.cz>>

On 02/12/2013 12:17 PM, Teemu Suikki wrote:


Hi!

I was trying to find source code for the rotor plugin (not
rotorng)..
all the links seem to be outdated. Anyone have any version?

I'm really only interested in seeing how the GotoX stuff works. I'm
trying to send gotox command from diseqc.conf, but the dish
doesn't move
at all.

I have the Eutelsat diseqc 1.2 specification, but the GotoX stuff is
marked preliminary and they talk only about terrestrial
antennas.. Must
be some difference.

Here's my non-functioning diseqc.conf entry:

#S1.0W - Elevation 17.44, Azimuth 209.62, Motor angle -28.45
S1.0W 11700 V  9750  t W15 [E0 31 6E 0D 07] W15 v t
S1.0W 9 V 10600  t W15 [E0 31 6E 0D 07] W15 v T
S1.0W 11700 H  9750  t W15 [E0 31 6E 0D 07] W15 V t
S1.0W 9 H 10600  t W15 [E0 31 6E 0D 07] W15 V T

I actually made a C program that generates these lines for all
visible
satellites. This might be of interest to people who are waiting for
gotox support, if I ever get this working..




_
vdr mailing list
vdr@linuxtv.org 
http://www.linuxtv.org/cgi-__bin/mailman/listinfo/vdr


Hi Teemu,

I'm using the patch based on patch from Seppo Ingalsuo (see
http://patchwork.linuxtv.org/__patch/12911/
) - this version I'm used
now with vdr-1.7.27 together with yaVDR, but have info that it works
also with later versions. Patch integrate gotoxx into VDR and works
without problems.

Regards,

Ales

_
vdr mailing list
vdr@linuxtv.org 
http://www.linuxtv.org/cgi-__bin/mailman/listinfo/vdr





--
Teemu Suikki
http://www.z-power.fi/


___
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] RFC: one or many positioners?

[Timothy D. Lenz]

Better to support multi-positioners. Makes options much more flexible.

On 4/21/2013 5:54 AM, Klaus Schmidinger wrote:

I'm currently implementing support for steerable dishes, loosely based
on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual
base class cPositioner, which defines all the functions necessary to
control the positioner. An implementation of cDiseqcPositioner will
allow control of "DiSEqC 1.2" and "USALS" motors. A plugin can derive
from cPositioner and implement its very own way of controlling a
positioner (like through a serial or USB port or whatever).

The question I have now is: will it be enough to have *one* single
positioner
in any given setup, or are there actually users who have more than one
positioner?
Supporting only a single positioner (as is done in the aforementioned
patch)
of course simplifies things quite a bit. So I wouldn't want to add this
level of complexity unless there is a real need for it.

Any opinions?

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] vdr 1.7 -> 2.1 upgrade tips (FHS)

[Timothy D. Lenz]

To me, dumping files all over the drives is messy, sloppy, and bad 
practice. Always has been and always will be. Someone just wants to copy 
MS stupidity into linux.


On 11/4/2013 2:16 PM, Klaus Schmidinger wrote:

On 04.11.2013 21:25, Lars Hanisch wrote:

Hi,

Am 04.11.2013 17:17, schrieb VDR User:

Hi,
Have a look to Make.config.template if you want to use vdr 2.x like
1.6
running in one single dir!


Yeah, I saw that sort of thing is doable but it's probably worth my
while doing things "properly" to fit in with the current way of
thinking.


It's not `improper` to keep the same pre-FHS structure. A lot of
people don't care about FHS. I personally don't like files spread out
all over the place. Instead I prefer things be kept in a single
location so things are easy to keep track of. For that reason, I also
use ONEDIR=1 in my vdr Make.config. I didn't have to move any files
anywhere and upgraded VDR with no problem.

Don't do something because someone else does it. Do it because it's
what you actually want. If you don't want it that way, why force
yourself to go against your own preference? Especially if you're using
linux where anything goes.


  And I'm pretty sure vdr will always support the "one directory"
setup, because Klaus is using it (as far as I know).


You bet! ;-)

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] New tool to load VDR with XMLTV Data

[Timothy D. Lenz]

So this would read data from Schedules Direct? I started trying to come 
up with something, but never got far with it.


On 12/23/2013 2:46 PM, Adam Flott wrote:

I wrote a tool to load VDR with XMLTV data. Written in Go with 0
external dependencies and does a few things nicer than that perl script
that's been floating around

Source: https://github.com/adamflott/vdr-epg-tool
Usage: http://adamflott.com/loading-vdr-with-xmltv-data/

Probably not 100% bug free, but it works for me.

$ tv_grab_na_dd --days 1 --output /tmp/epg_schedules_direct.xml \
   && vdr-epg-tool -c /var/lib/vdr/channels.conf -x
/tmp/epg_schedules_direct.xml epg-load \
   && rm /tmp/epg_schedules_direct.xml


Enjoy!


___
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 atsc support

[Timothy D. Lenz]

On 3/25/2016 11:55 AM, Joerg Bornkessel wrote:

Am 24.03.2016 um 07:35 schrieb Mika Laitio:

Does anybody know whether there is a working ATSC vdr-plugin
available somewhere?

I found some old discussions from the some ATSC plug-in from the
mailing list pointing to http://www.fepg.org/ but from those I got
an impression that plug-in is not actively maintained?

So fat I have tested that I can scan and look the channels fine
with the Kaffeine and WinTV-HVR-950Q, but in the long run I would
be more interested on running the VDR in normal way on background
server.

Mika



ATSC is supported in the Core VDR.
Iam kontakted the Maintainer Alex Lasnier a lot of month ago for an
update for the
vdr-plugin-atscepg
This plugin is definitely dead on upstream since 2010 and is not
supported by the Maintainer anymore.
Anyway...
The maintainer has give me access to his privat git for some local
fixes by him self.
I dont remeber for this link.
You can download the latest version atscepg-0.3.0 from fepg.org
and you need an aditional patch from my dev webspace to get the latest
fixes from him.

https://dev.gentoo.org/~hd_brummy/distfiles/atscepg-0.3.0_vdr-1.7.13.tbz

also you have to disable -std=c++11 support on latest gcc versions to
fix c++11 issues on compiletime.

I have this tested only for compile as i dont have access to atsc conten
t.

Cheers

/dev/joerg
___


I have been using this plugin for years. Haven't touched the computer in 
years as far as updating kernal or vdr. It says the version for ATSC 
0.3.0hg. I think the main use of the plugin is channel scanning to find 
what channels are active. But For me it segfaults 95% of the time. Seems 
like maybe something in the stream. Because every so often, It works 
just fine. I can scan over and over no problem. But most of the time it 
segfaults as soon as you tell it to scan.


Another problem I have here in Tucson is the broadcasters don't know 
what a standard is. There is some flag the don't set to tell vdr there 
is guide data, so it's not collected even though a cheap converter box 
has no problem with it. But then they are doing good to put up more then 
a day or 2 of data anyway and PBS for awhile put in stream what was 
posted at all the web sites, but then made up their own guide and you 
had to go to a local web site to get the real guide.


Also, several of our channels are broadcast from 2 locations on 
different frequencys, but carry the same data. VDR doesn't know how to 
handle that, so you have to delete one of the entries. My old sony tv 
and others have the same problem. They see the second copy and pick some 
new number based on the frequancy number instead of the assigned number. 
A bit of a pain. Looks like it might be fixed in newer high end tv's 
(and the old cheap converter box also had no problem with dupe channel 
numbers.)


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

[vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

So I'm using an old version of VDR, looks like 1.7.15 with the ATSC
plugin. Just don't have the time to update everything. I noticed that
the 9x locals stopped getting guide data. I did a new scan and the new
list worked for 9x but would wipe 58x channels. comparing them, they
changed the next to last field entry for 9x from 215 to 207 which is the
same as for the 58x. That's the only reason I see. I can switch to 9x

---
:@91
KGUN-DT,KGUN-DT:189028615:M10:A:0:49=2:0;53=esl@106,52=eng@106:0:0:3:0:215:0
:@92
Laff   ,Laff   :189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:215:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0
---
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
:@582
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@583
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
---

Old List:

:@41
KVOA,KVOA:527028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:527028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@61
PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0
:@62
V-Me,V-Me:569028615:M10:A:0:65=2:0;68=eng@106,72=eng@106:0:0:2:0:213:0
:@63
ReadyTV,ReadyTV:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0
:@91
KGUN-DT,KGUN-DT:189028615:M10:A:0:49=2:0;53=esl@106,52=eng@106:0:0:3:0:215:0
:@92
Laff   ,Laff   :189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:215:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0
:@111
KMSB-HD,KMSB-HD:539028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:217:0
:@112
Movies,Movies:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0
:@113
Justice,Justice:539028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:217:0
:@131
KOLD DT,KOLD DT:581028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:219:0
:@132
Me TV,Me TV:581028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0
:@133
Grit,Grit:581028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0
:@141
KUDF-LP,KUDF-LP:473028615:M10:A:0:81=2:0;84=esl@106:0:0:3:0:8263:0
:@181
KTTU-HD,KTTU-HD:503028615:M10:A:0:49=2:0;52=eng@106:0:0:1:0:221:0
:@182
Estrell,Estrell:503028615:M10:A:0:65=2:0;68=esl@106:0:0:2:0:221:0
:@211
HSN,K21CX-D:515028615:M10:A:0:481=2:0;482=eng@106:0:0:1:0:1:0
:@271
PBS HD,PBS HD:557028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:223:0
:@272
KIDS,KIDS:557028615:M10:A:0:65=2:0;68=eng@106,72=eng@106:0:0:2:0:223:0
:@273
WORLD,WORLD:557028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:223:0
:@341
KFTU-CD,KFTU-CD:497028615:M10:A:0:49=2:0;52=esl@106,53=mul@106:0:0:1:0:7037:0
:@342
KUVE-HD,KUVE-HD:497028615:M10:A:0:65=2:0;68=esl@106,69=mul@106:0:0:2:0:7037:0
:@401
KHRR-DT,KHRR-DT:629028615:M10:A:0:49=2:0;52=esl@106:0:0:3:0:225:0
:@402
Exitos ,Exitos :629028615:M10:A:0:65=2:0;68=esl@106:0:0:4:0:225:0
:@403
ION,ION:629028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:225:0
:@421
KUVE-CD,KUVE-CD:641028615:M10:A:0:49=2:0;52=esl@106,53=mul@106:0:0:1:0:9307:0
:@422
KFTU,KFTU:641028615:M10:A:0:65=2:0;68=esl@106,69=mul@106:0:0:2:0:9307:0
:@423
KUVE-D3,KUVE-D3:641028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:9307:0
:@424
KUVE-D4,KUVE-D4:641028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:9307:0
:@461
KUVE-DT,KUVE-DT:665028615:M10:A:0:49=2:0;52=esl@106,53=mul@106:0:0:1:0:179:0
:@462
KFTU-HD,KFTU-HD:665028615:M10:A:0:65=2:0;68=esl@106,69=mul@106:0:0:2:0:179:0
:@463
getTV,getTV:665028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:179:0
:@464
ESCAPE,ESCAPE:665028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:179:0
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
:@582
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@583
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0

---

New List:

:@41
KVOA,KVOA:527028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:527028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@43
ESCAPE,ESCAPE:527028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:211:0
:@61
PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0
:@62
KIDS,KIDS:569028615:M10:A:0:65=2:0;68=eng@106,72=eng@106:0:0:2:0:213:0
:@63
PBS 6+,PBS 6+:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;53=esl@106,52=eng@106:0:0:3:0:207:0
:@92
LAFF,LAFF:189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@94
Bounce,Bounce:189028615:M10:A:0:97=2:0;100=eng@106:0:0:6:0:207:0
:@111
KMSB-HD,KMSB-HD:539028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:217:0
:@112
Movies,Movies:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0
:@113
Justice,Justice:539028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:217:0
:@114
Quest,Quest:539028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:217:0
:@131
KOLD DT,KOLD DT:581028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:219:0
:@132
Me 

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

Haven't used the list in awhile I I think my first reply went to the 
wrong address. So redoing plus adding some info.


91 is 9.1 KGUN which is the local for ABC Broadcast Network A National 
Network. The other 9.x channels are assorted small stations. 581 or 58.1 
is CW, Another big network. They are very different. 58.2 is some 
spanish channel using sub channel space.


And here is the channel.conf provided by ATSCEPG plugin:

:@41
KVOA,KVOA:69028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:69028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@43
ESCAPE,ESCAPE:69028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:211:0
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
:@92
LAFF,LAFF:189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@94
Bounce,Bounce:189028615:M10:A:0:97=2:0;100=eng@106:0:0:6:0:207:0
:@131
KOLD DT,KOLD DT:213028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:219:0
:@132
Me TV,Me TV:213028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0
:@133
Grit,Grit:213028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0
:@141
KUDF-HD,KUDF-HD:473028615:M10:A:0:49=2:0;52=spa@106:0:0:1:0:8263:0
:@142
Telemax,Telemax:473028615:M10:A:0:65=2:0;68=spa@106:0:0:2:0:8263:0
:@143
GNTVLat,GNTVLat:473028615:M10:A:0:81=2:0;84=spa@106:0:0:3:0:8263:0
:@144
GoodNws,GoodNws:473028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:8263:0
:@91
KGUN-HD,KGUN-HD:485028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
:@92
LAFF,LAFF:485028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@93
Antenna,Antenna:485028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@94
Bounce,Bounce:485028615:M10:A:0:97=2:0;100=eng@106:0:0:6:0:207:0
:@341
KFTU-CD,KFTU-CD:497028615:M10:A:0:49=2:0;52=spa@106,53=mul@106:0:0:1:0:7037:0
:@342
KUVE-HD,KUVE-HD:497028615:M10:A:0:65=2:0;68=spa@106,69=mul@106:0:0:2:0:7037:0
:@181
KTTU-HD,KTTU-HD:503028615:M10:A:0:49=2:0;52=eng@106:0:0:1:0:221:0
:@182
Estrell,Estrell:503028615:M10:A:0:65=2:0;68=spa@106:0:0:2:0:221:0
:@183
H and I,H and I:503028615:M10:A:0:81=2:0;83=eng@106:0:0:3:0:221:0
:@211
HSN,K21CX-D:515028615:M10:A:0:481=2:0;482=eng@106:0:0:1:0:1:0
:@41
KVOA,KVOA:527028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:527028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@43
ESCAPE,ESCAPE:527028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:211:0
:@111
KMSB-HD,KMSB-HD:539028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:1:0:217:0
:@112
Movies,Movies:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0
:@113
Justice,Justice:539028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:217:0
:@114
Quest,Quest:539028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:217:0
:@271
PBS HD,PBS HD:557028615:M10:A:0:49=2:0;52=eng@106,56=@106:0:0:1:0:223:0
:@272
KIDS,KIDS:557028615:M10:A:0:65=2:0;68=eng@106,72=@106:0:0:2:0:223:0
:@273
PBS 6+,PBS 6+:557028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:223:0
:@61
PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0
:@62
KIDS,KIDS:569028615:M10:A:0:65=2:0;68=spa@106,72=spa@106:0:0:2:0:213:0
:@63
PBS 6+,PBS 6+:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0
:@131
KOLD DT,KOLD DT:581028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:219:0
:@132
Me TV,Me TV:581028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0
:@133
Grit,Grit:581028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0
:@401
KHRR-DT,KHRR-DT:629028615:M10:A:0:49=2:0;52=spa@106:0:0:3:0:225:0
:@402
Exitos ,Exitos :629028615:M10:A:0:65=2:0;68=spa@106:0:0:4:0:225:0
:@403
ION,ION:629028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:225:0
:@421
KUVE-CD,KUVE-CD:641028615:M10:A:0:49=2:0;52=spa@106:0:0:1:0:9307:0
:@422
KFTU,KFTU:641028615:M10:A:0:65=2:0;68=spa@106,69=mul@106:0:0:2:0:9307:0
:@423
KUVE-D3,KUVE-D3:641028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:9307:0
:@424
KUVE-D4,KUVE-D4:641028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:9307:0
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
:@582
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@583
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@461
KUVE-DT,KUVE-DT:665028615:M10:A:0:49=2:0;52=spa@106,53=mul@106:0:0:1:0:179:0
:@462
KFTU-HD,KFTU-HD:665028615:M10:A:0:65=2:0;68=spa@106,69=mul@106:0:0:2:0:179:0
:@463
getTV,getTV:665028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:179:0
:@464
ESCAPE,ESCAPE:665028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:179:0


On 3/7/2018 3:04 AM, Klaus Schmidinger wrote:

On 07.03.2018 00:04, Timothy D. Lenz wrote:

So I'm using an old version of VDR, looks like 1.7.15 with the ATSC
plugin. Just don't have the time to update everything. I noticed that
the 9x locals stopped getting guide data. I did a new scan and the new
list worked for 9x but would wipe 58x channels. comparing them, they
changed the next to last field entry for 9x from 215 to 207 which is the
same as for the 58x. That's the only reason I see. I can switch to 9x
...


Using the same NID, TID and SID makes these cha

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

I was hoping it was something simple I could fix in the conf. I haven't 
worked on it or in linux in a long time and don't have the free time to 
figure it all out again. I'll have to look at this some other time. I am 
in the U.S. and these are ATA channels. They each have their own freq. 
and my guess is that they can use what ever numbers they want since they 
are on there own freq which they bought.


On 3/8/2018 2:51 AM, Klaus Schmidinger wrote:

On 08.03.2018 03:36, Timothy D. Lenz wrote:
Haven't used the list in awhile I I think my first reply went to the 
wrong address. So redoing plus adding some info.


91 is 9.1 KGUN which is the local for ABC Broadcast Network A National 
Network. The other 9.x channels are assorted small stations. 581 or 
58.1 is CW, Another big network. They are very different. 58.2 is some 
spanish channel using sub channel space.


And here is the channel.conf provided by ATSCEPG plugin:

...
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0 


...
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0 


...


The four rightmost numbers are SID:NID:TID:RID. These values are used to 
compose
the "channel id". So these channels have exactly the same "id", and thus 
are
"the same" to VDR. Since you are saying that these are in fact very 
different

channels (presumably with different EPG), it is just plain wrong to use the
same values for NID, TID and SID (RID=0 is irrelevant). The question is: 
who

does it wrong? If these values are broadcast as such in the SDT, it´s the
broadcaster´s fault. If they are correct (i.e. different for each channel)
in the SDT, it´s the ATSCEPG plugin´s fault.

To see which values are broadcast, you can set

static bool DebugSdt = true;

in sdt.c.

Klaus

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


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

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

I sent an email to KGUN and if they don't fix the conflict right away, I 
guess I'll have to make a complaint to the FCC, not that it will do much 
good.


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the 
free time to figure it all out again. I'll have to look at this some 
other time. I am in the U.S. and these are ATA channels. They each 
have their own freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

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


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

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x 
and using it for 58.x. So 58.x data is now being lost. g


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the 
free time to figure it all out again. I'll have to look at this some 
other time. I am in the U.S. and these are ATA channels. They each 
have their own freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

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


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

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

I told a neighbor about this who used to work in Broadcast many years 
ago locally. And back then when they were just setting up the digital 
gear for the switch over, she said the engineers they where bringing in 
were not engineers and had little clue what they were doing. It's only 
gotten worse.


She did hear something about CW and KGUN local stations now being owned 
by the same company.


Another problem is, I built this using an Asus motherboard. I will never 
buy anything from them again. I have had a number of Asus boards and and 
all have had problems. All where unstable and VERY picky about what 
cards you used. Swap the motherboard and nothing else and all the 
strange problems would go away. One of the problems I have is that when 
I try to run the ATSC plugin's channel scan, 80-90% of the time it 
crashes VDR and no one could figure out why. Sometimes it works just 
fine. other times no. And it looks like I won't be getting any more 
scans for awhile because it is back to crashing. Maybe some day I'll get 
the time and money and time to build another system.. someday...


On 3/10/2018 1:30 AM, Klaus Schmidinger wrote:

On 10.03.2018 01:21, Torgeir Veimo wrote:

Isn't there a plugin that can change such data before it gets processed?


The problem is that these are *duplicate* channels - they can't be in the
channel list to begin with. They need to have different Transport Stream 
Ids.
And as wen can see from Timothy's old channel list, they used to have 
these.

So somebody just screwed up!

Klaus

On 10 March 2018 at 08:47, Timothy D. Lenz <mailto:tl...@vorgon.com>> wrote:


    Wel, it gets better. Tonight I see VDR is grabbing guide data 
for 9x and using it for 58.x. So 58.x data is now being lost. g



    On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

    On 08.03.2018 22:38, Klaus Schmidinger wrote:

    On 08.03.2018 22:13, Timothy D. Lenz wrote:

    I was hoping it was something simple I could fix in 
the conf. I haven't worked on it or in linux in a long time and don't 
have the free time to figure it all out again. I'll have to look at 
this some other time. I am in the U.S. and these are ATA channels. 
They each have their own
    freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.



    Well, it's funny though that they use exactly the same IDs 
;-).


    Sure they can do whatever they want, but there are a few 
basic rules that
    should be followed in order to guarantee a reasonable 
coexistance. One of
    them is that channels that are broadcast in the same area 
(like from the
    same terrestrial transmitter, on the same cable or the 
same satellite)
    should use unique IDs, even if they are on different 
transponders. One
    of these IDs is the "transport stream id", which in your 
case is 207 for

    both channels. This should be different.


    For testing I added your new channel list to my channels.conf.
    Here's what my VDR reported upon startup:

    Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


    With your old list I get no such log entries. So I guess 
somebody messed up

    with the TIDs, and the problem should be fixed there.

    Klaus


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


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

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

It turns out that both stations are owned by the same company. I have 
sent KGUN9 a second email about the conflict and reported it to the FCC 
as interference because they interfering with each other. Looking at 
this site: https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf


I found this near the end:

"RID
Radio ID. Typical 0. Can be used to differentiate between channels 
having the same SID, NID and TID."


For some reason or another, I had to set all ATSC RID's to 0 for 
everything to work.  I changed them to the entries in my conf but it 
doesn't seem to be working. Channels are not being deleted, but 
something is still wrong. Might be a problem with vdr admin.  I had to 
add entries for a sat broadcast which (is scrambed) as 90 or 91 would 
not show. letting it set for a bit, looks like now I am seeing 581 guide 
data for 91. :(


On 3/10/2018 1:30 AM, Klaus Schmidinger wrote:

On 10.03.2018 01:21, Torgeir Veimo wrote:

Isn't there a plugin that can change such data before it gets processed?


The problem is that these are *duplicate* channels - they can't be in the
channel list to begin with. They need to have different Transport Stream 
Ids.
And as wen can see from Timothy's old channel list, they used to have 
these.

So somebody just screwed up!

Klaus

On 10 March 2018 at 08:47, Timothy D. Lenz <mailto:tl...@vorgon.com>> wrote:


    Wel, it gets better. Tonight I see VDR is grabbing guide data 
for 9x and using it for 58.x. So 58.x data is now being lost. g



    On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

    On 08.03.2018 22:38, Klaus Schmidinger wrote:

    On 08.03.2018 22:13, Timothy D. Lenz wrote:

    I was hoping it was something simple I could fix in 
the conf. I haven't worked on it or in linux in a long time and don't 
have the free time to figure it all out again. I'll have to look at 
this some other time. I am in the U.S. and these are ATA channels. 
They each have their own
    freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.



    Well, it's funny though that they use exactly the same IDs 
;-).


    Sure they can do whatever they want, but there are a few 
basic rules that
    should be followed in order to guarantee a reasonable 
coexistance. One of
    them is that channels that are broadcast in the same area 
(like from the
    same terrestrial transmitter, on the same cable or the 
same satellite)
    should use unique IDs, even if they are on different 
transponders. One
    of these IDs is the "transport stream id", which in your 
case is 207 for

    both channels. This should be different.


    For testing I added your new channel list to my channels.conf.
    Here's what my VDR reported upon startup:

    Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


    With your old list I get no such log entries. So I guess 
somebody messed up

    with the TIDs, and the problem should be fixed there.

    Klaus


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


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

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

Standards??? what's that? Only thing around here that is standard is to 
be proprietary


On 3/11/2018 2:19 PM, Klaus Schmidinger wrote:

On 11.03.2018 22:10, Timothy D. Lenz wrote:
It turns out that both stations are owned by the same company. I have 
sent KGUN9 a second email about the conflict and reported it to the 
FCC as interference because they interfering with each other. Looking 
at this site: 
https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf


I found this near the end:

"RID
Radio ID. Typical 0. Can be used to differentiate between channels 
having the same SID, NID and TID."


Introducing the RID was a pretty ugly workaround.
I suggest not to use it and rather try and find somebody at the
broadcaster who knows his stuff ;-).

My guess is they simply copy/pasted the configuration
for these channels and didn't bother adhering to standards.

Klaus

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


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

[vdr] How to open the Hauppauge curved remote for cleaning??

[Timothy D. Lenz]

I know it can be done, I've done it before. I've cleaned lots of other 
remotes. But there is some trick to getting one of these open and I 
can't figure it out. The "OK" butting needs cleaning.


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

[vdr] VDR system on Raspberry pi vs these all in one systems

[Timothy D. Lenz]

My mom (82 years old) is still using a VCR with a tuner box. We are 
concerned about it wearing out, the tapes no longer being sold, etc.. 
She just spent $65 on a 9 pack of tapes from Amazon that could have gone 
to a new setup and she is saying she wants to get another VCR for 
backup. But they haven't been made in years, so it would already be 
used. I have a linux computer running VDR with a couple of dual ATSC 
dual tuner cards. But it needs to be rebuilt/reinstalled and I haven't 
messed with it in so long, I would have to learn it all over again and 
I'm not as good at figuring stuff out as I used to be and money is tight.


You can get VDR/Linux images ready to go for a Raspberry pi which cost 
about $35. Add a USB Tuner and a USB drive and you have a digital 
recorder system. And if I ever get mine rebuilt, they could be linked 
and share tuners and drive space. But it's complicated and time 
consuming to setup for me atm.


These ready made units would be simpler to get going, but a good one 
would cost more and be more complicated for her to use. I still have to 
setup timers for recording with the VCR.


I'm looking for recommendations/options/opinions. While the local over 
the air guide is mostly a mess, sometimes not sending out the prime time 
data till nearly noon of that day, we'd want to avoid having to sub to 
any service to keep cost down. Needs to be local recording, be able to 
use local guide data and when needed setup blind recordings as done on 
VCRs, and would be nice if you could plug and remove USB drives/sticks 
for longer term storing recordings. From what I've seen, these ready 
made systems don't really like media swapping.


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

[vdr] Rotor/livebuffer links down

[Timothy D. Lenz]

Seems all the links at http://home.vrweb.de/~bergwinkl.thomas/ for the rotor
plugin and livebuffer are down.

Object not found!
The requested URL was not found on this server. The link on the referring
page seems to be wrong or outdated. Please inform the author of that page
about the error.

If you think this is a server error, please contact the webmaster.

Error 404
pphl.opencounter.de
Thu Aug 23 21:35:14 2007
Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-22


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

[vdr] Rotor plugin crashing with valid data in diseqc.conf

[Timothy D. Lenz]

Built a new system with an Athlon64 x2 running and64 linux. I went with
vdr-1.5.9. I tried to use the diseqc.conf from my old system, but vdr
crashes in startup when the rotor plugin is used. I found the problem seems
to be the use of commands to control the rotor in the diseqc.conf. with [E0
31 6B 26] and rotor plugin, vdr crashes at startup. remove ether the rotor
plugin or all [E0 31 6B xx] entries and it starts. I used the vdr-1.5.5
patch in the patches folder of rotor.

Starting VDR - Linux Video Disk Recorder: runvdr.

*** glibc detected *** /usr/local/bin/vdr: munmap_chunk(): invalid pointer:
0x05613804 ***
=== Backtrace: =
/lib/libc.so.6(cfree+0x1b6)[0x2aff4f3486b6]
/usr/local/bin/PLUGINS/lib/libvdr-rotor.so.1.5.9(_ZN12cPluginRotor5StartEv+0
x299)[0x2aff53aac659]
/usr/local/bin/vdr(_ZN14cPluginManager12StartPluginsEv+0x5d)[0x49bc6d]
/usr/local/bin/vdr(main+0x1496)[0x4cd626]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2aff4f2f0b44]
/usr/local/bin/vdr(__gxx_personality_v0+0x229)[0x44b849]
=== Memory map: 
0040-0052d000 r-xp  03:01 1736706
/usr/local/bin/vdr
0072c000-0073 rw-p 0012c000 03:01 1736706
/usr/local/bin/vdr
0073-0562b000 rw-p 0073 00:00 0
[heap]
4000-40001000 ---p 4000 00:00 0
40001000-40801000 rw-p 40001000 00:00 0
40801000-40802000 ---p 40801000 00:00 0
40802000-41002000 rw-p 40802000 00:00 0
41002000-41003000 ---p 41002000 00:00 0
41003000-41803000 rw-p 41003000 00:00 0
41803000-41804000 ---p 41803000 00:00 0
41804000-42004000 rw-p 41804000 00:00 0
42004000-42005000 ---p 42004000 00:00 0
42005000-42805000 rw-p 42005000 00:00 0
42805000-42806000 ---p 42805000 00:00 0
42806000-43006000 rw-p 42806000 00:00 0
2c00-2c021000 rw-p 2c00 00:00 0
2c021000-2aaab000 ---p 2c021000 00:00 0
2aff4de26000-2aff4de43000 r-xp  03:01 819205
/lib/ld-2.6.1.so
2aff4de43000-2aff4de46000 rw-p 2aff4de43000 00:00 0
2aff4de46000-2aff4df7e000 r--p  03:01 1281421
/usr/lib/locale/locale-archive
2aff4e042000-2aff4e044000 rw-p 0001c000 03:01 819205
/lib/ld-2.6.1.so
2aff4e044000-2aff4e065000 r-xp  03:01 1262770
/usr/lib/libjpeg.so.62.0.0



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

Re: [vdr] Rotor plugin crashing with valid data in diseqc.conf

[Timothy D. Lenz]

Applied the patch and started with the problem conf. Not much help. Only
mention I found of any problem was in the syslog:

Sep 21 15:38:59 x64VDR vdr: [20139] starting plugin: dvd
Sep 21 15:38:59 x64VDR vdr: [20139] starting plugin: femon
Sep 21 15:38:59 x64VDR vdr: [20139] starting plugin: weatherng
Sep 21 15:38:59 x64VDR vdr: [20139] plugin 'weatherng' called obsolete
function RegisterI18n()
Sep 21 15:38:59 x64VDR vdr: [20139] starting plugin: rotor
Sep 21 15:38:59 x64VDR vdr: [20139] plugin 'rotor' called obsolete function
RegisterI18n()
Sep 21 15:38:59 x64VDR vdr: [20139] loading /etc/vdr/plugins/rotor.conf
Sep 21 15:38:59 x64VDR vdr: [20150] CI adapter on device 0 thread started
(pid=20139, tid=20150)
Sep 21 15:38:59 x64VDR vdr: [20153] EPGSearch: conflictcheck thread started
(pid=20139, tid=20153)

The Weatherng plugin, thoug showing the same error, seems ok.

- Original Message - 
From: "Igor" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, September 21, 2007 2:40 AM
Subject: Re: [vdr]Rotor plugin crashing with valid data in diseqc.conf

> may be the logs in syslog from rotor plugin will help to you. For this you
need to use this path
>
> --- 1/dvbdevice.c 2007-09-07 21:54:12.0 +0200
> +++ 2/dvbdevice.c 2007-09-10 18:52:42.0 +0200
> @@ -168,6 +168,7 @@
>  dvb_frontend_event Event;
>  while (ioctl(fd_frontend, FE_GET_EVENT, &Event) == 0)
>; // just to clear the event queue - we'll read the actual
status below
> +   isyslog("Rotor-command %X %X %X %X %X
sent",diseqc_cmd.msg[0],diseqc_cmd.msg[1],diseqc_cmd.msg[2],diseqc_cmd.msg[3
],diseqc_cmd.msg[4]);/*MIROHA*/
>  }
>   }
>while (1) {
>
>
>
> Igor


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

Re: [vdr] Rotor plugin crashing with valid data in diseqc.conf

[Timothy D. Lenz]

Any more ideas on this? Not sure why rotor plugin would even need to look at
the diseqc.conf. For moving the dish on channel switch, it can get the sat
location from the 4th entry in the channels.conf. Why would it need to deal
with diseqc commands in the diseqc.conf when it was fine with them before?
Anything chang in 1.5.x that would require a change like this? because the
plugin is crashing the same way with 1.4.6. So it must have somthing to do
with changes to make it work with 1.5.x

- Original Message - 
From: "Igor" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, September 21, 2007 2:40 AM
Subject: Re: [vdr]Rotor plugin crashing with valid data in diseqc.conf


> > Built a new system with an Athlon64 x2 running and64 linux. I went with
> > vdr-1.5.9. I tried to use the diseqc.conf from my old system, but vdr
> > crashes in startup when the rotor plugin is used. I found the problem
seems
> > to be the use of commands to control the rotor in the diseqc.conf. with
[E0
> > 31 6B 26] and rotor plugin, vdr crashes at startup. remove ether the
rotor
> > plugin or all [E0 31 6B xx] entries and it starts. I used the vdr-1.5.5
> > patch in the patches folder of rotor.
>
>
> may be the logs in syslog from rotor plugin will help to you. For this you
need to use this path
>
> --- 1/dvbdevice.c 2007-09-07 21:54:12.0 +0200
> +++ 2/dvbdevice.c 2007-09-10 18:52:42.0 +0200
> @@ -168,6 +168,7 @@
>  dvb_frontend_event Event;
>  while (ioctl(fd_frontend, FE_GET_EVENT, &Event) == 0)
>; // just to clear the event queue - we'll read the actual
status below
> +   isyslog("Rotor-command %X %X %X %X %X
sent",diseqc_cmd.msg[0],diseqc_cmd.msg[1],diseqc_cmd.msg[2],diseqc_cmd.msg[3
],diseqc_cmd.msg[4]);/*MIROHA*/
>  }
>   }
>while (1) {
>
>
>
> Igor


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

Re: [vdr] Not good behaviour from vdr

[Timothy D. Lenz]

I don't know about it restarting. The crashing with loss of signal is
suposed to be a safe guard against creating blank recordings. Seems like a
bad idea to me to. Just delete the bad recordings, don't crash the system.
Here is the fix we've been using:

Locate the line in recorder.c and comment it out.

   esyslog("ERROR: video data stream broken");
-  ShutdownHandler.RequestEmergencyExit();
+ //   ShutdownHandler.RequestEmergencyExit();

- Original Message - 
From: "JJussi" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, September 28, 2007 11:49 PM
Subject: [vdr] Not good behaviour from vdr


> Hi!
>
> Yesterday, here at Southern Finland one of the TV channels had "cut out"
at
> DVB stream (like half hour). And because that stream disapeared little
after
> than recoding has started, VDR started to restart itself every minute
because
> there was no stream...
> What is point to that, that VDR do restart IF there is no stream what it
> should record.. That affected to all other recordings too because vdr was
> restarting itself constantly. Not good!
> Is there "setting" somewhere where you can say that "do not" restart if
there
> is no stream.
>
> -- 
> JJussi
>
> ___
> 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] Not good behaviour from vdr

[Timothy D. Lenz]

Should be on loss if video, not just loss of signal. Doesn't happen often, but 
I have seen video go during a storm while femon still says there is a lock.
  - Original Message - 
  From: Stone 
  To: VDR Mailing List 
  Sent: Sunday, September 30, 2007 11:38 AM
  Subject: Re: [vdr] Not good behaviour from vdr


  I like the idea of appending the "?" symbol to every recording that triggers 
the "no signal" flag.

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

[vdr] multi diseqc.conf setup

[Timothy D. Lenz]

I have a nexus and am getting a usb tunner. I have 2 fixed dishes and a
rotor. All the lnb's can feed 2 tunners, but clearly the lnb's on the rotor
can only see 1 sat. It would be nice if there was a way to add more
diseqc.conf or entries for same sats but alternate feeds so that when the
dish is pointing at sat other then the ones the fixed dishes are, the other
tunner can know to use those allowing tunning from more then 1 sat at a
time.


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

Re: [vdr] VDR doesn't always switch channel correctly

[Timothy D. Lenz]

He has a Dish Pro LNB. The switching is done via the two LO settings. He
wants V high always for propper operration of the LNB. They like the voltage
to be at 18-19v

Try increasing the delay a tad. change the W15's to W20 and the first W20's
to W25's. The W20's at the end I don't think are needed.

- Original Message - 
From: "Thiemo" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, November 09, 2007 3:07 AM
Subject: Re: [vdr] VDR doesn't always switch channel correctly


> Am Donnerstag 08 November 2007 schrieb Maxime Laplante:
> > Hi guys,
> >
> > I'm running VDR 1.4.0 on my CaptiveWorks CW-3000HD FTA receiver.
> >
> > My current diseqc.conf is:
> >
> > # DiseqC Configuration
> >
> > # Port 0 Galaxy 11 & Nimiq 1,3
> > S91.0W 9 V 11250 t V W15 [E0 10 38 F2] W20 [E0 10 38 F2] W20
> > S91.0W 9 H 14350 t V W15 [E0 10 38 F2] W20 [E0 10 38 F2] W20
> > S91.0W 9 R 11250 t V W15 [E0 10 38 F2] W20 [E0 10 38 F2] W20
> > S91.0W 9 L 14350 t V W15 [E0 10 38 F2] W20 [E0 10 38 F2] W20
>
> I dont see how switching the polarisation is done - as toneburst, voltage
and
> diseqc commands are all the same for each polarisation.
> Also a repeated command should start with "E1" because "E0" would be for
the
> next (cascaded) switch which is most probably not what was intended...
> You could also repeat the commands twice, which is the default.
> A correct diseqc block with 2 repeats should look like this:
>
> S19.2E  11700 V   9750 t v W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10
38
> F0] W15  t
> S19.2E  9 V  10600 t v W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10
38
> F1] W15  T
> S19.2E  11700 H   9750 t V W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10
38
> F2] W15  t
> S19.2E  9 H  10600 t V W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10
38
> F3] W15  T
>
> regards,
> T.
>
> ___
> 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] ATSC

[Timothy D. Lenz]

Any chance we can get ATSC tunner card support with the next branch of vdr?
In 1 year from today it will replace all analog TV broadcast in the US.


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

Re: [vdr] ATSC

[Timothy D. Lenz]

I found a patch  for at least some ATSC cards. Not sure about which work and
which don't: http://fepg.freehostia.com/
There is also a ATSCEPG plugin needed for EPG.
This information was posted at:
http://dvbn.happysat.org/viewtopic.php?t=44680&start=15

I'm mainly interrested in cards with at least dual ATSC tuning. 1 or more of
the devices out there use the LG tuning chip which is suposed to by far the
best. There is also a networked tuner that looks interresting which is
supported by MythTV. Don't know what chip set it has or if it can work with
VDR. Tuners I've been looking at:

http://www.pchdtv.com/ Seems to be designed for use with linux and uses the
LG chip but is only a single tuner.

http://www.bbti.us/products_airstar_hd5000_pci.htm

http://www.vboxcomm.com/product3.htm#4 Cat's Eye 164e dual tuner but chip
set unknown.

http://techluver.com/2008/01/07/hauppauge-intros-wintv-hvr-2250-1950-950q-and-1250/
The did a nice job wit hthe Nexus. The 2250 is a brand new dual tuner card.
Not much info on their site yet. Reported to be the final version to the
PCV530 ref design which did use LG chips, but not in the tuner.

http://www.silicondust.com/wiki/products/hdhomerun Connects via LAN, Dual
tuner, chipset unknown. Known to work with MythTV, but VDR unknown.

- Original Message - 
From: "Steffen Barszus" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, February 23, 2008 10:15 AM
Subject: Re: [vdr] ATSC


> Timothy D. Lenz schrieb:
> > Any chance we can get ATSC tunner card support with the next branch of
vdr?
> > In 1 year from today it will replace all analog TV broadcast in the US.
> >
> >
> Think that depends solely on what interface these cards - are they using
> linux-dvb api ?
>
> ___
> 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] [patch] channels with same pids

[Timothy D. Lenz]

Trying working with NA sats. At least in Europe you have standards. Here the
only standard is that there is no standard.
For example, on 97w after using a custome scanner, if I allow VDR to auto
update channel names, then surf through the channels with a fresh conf, some
channels dissapear, others get renamed to wrong names, etc.. Using yaepg
while fliping through I can see some channels get shuffled and renamed.

- Original Message - 
From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, February 24, 2008 7:00 AM
Subject: Re: [vdr] [patch] channels with same pids


> On 02/24/08 12:35, Igor wrote:
> >> Have you ever tried complaining to those providers, telling them about
> >> their non-standard behavior?
> >
> > I have tried. Several times. No results.
>
> I wonder why these people think that the DVB standards don't apply to
them...
>
> > I can confirm that only VDR has this problem. Other receivers (dreambox
for example) don't have this problem.
>
> Does this mean that the dreambox doesn't identify channels using
NID/TID/SID?
>
> VDR itself doesn't use the RID, and I don't like starting to use it
> just to iron out the inability of some providers to adhere to the
standard.
> I'd rather like to get rid of the RID altogether.
>
> 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

[vdr] HDHomeRun need IPTV plugin?

[Timothy D. Lenz]

Has anyone got the  HDHomeRun to work with VDR? It's one of the dual ATSC
tuners I'm looking into for adding ATSC to my system. I'm thinking maybe
with the IPTV plugin it might work?

Also wondering how good it's tuning is compaired to tuners using the LG
DT3303 which seems to be the bench mark to aim for. The HDHomeRun has been
shiped with 2 different tuners according to the admin at their forum:
Rev 1.x uses the Oren CAS220 chipset.
Rev 2.x uses the latest generation Micronas DRXJ chipset.


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

[vdr] Feeds for IPTV plugin

[Timothy D. Lenz]

I spent awhile googling IPTV to see what could be used with this plugin. The
big network sites like NBC and CBS came up and they do list shows you can
"watch online". But I found none of the info that would be needed to
configure the plugin to work with these sites. Other sites that came up
where www.dishnetpc.com/ and www.direct-pctv.com/ which claim unlimited
access to 9000 channels if you buy their $40 software. Something noticably
lacking from those sites is a REAL LIST of the channels they give access to.
And even if they where legit, there is nothing there that indicates they
would work with vdr and the plugin.

So just what can be used with the IPTV plugin? Any links to sites known to
work?


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

[vdr] sub channel numbering system

[Timothy D. Lenz]

Would it be possible to add support for the subchannel numbering system used
with ATSC? Exmple of the channels in our area:

4   KVOA
4.1KVOAD
6   KUAT
6.1KUATD1
6.2KUATK
6.3KUATV
6.4KUATC
9   KGUN
9.1KGUND
11 KMSB
11.1  KMSBH
13 KOLD
13.1  KOLD-DT
14 KUDF
18 KTTU
18.1  KTTUDT
27 KUAS
27.1  KUASHD
34 KFTU
38 KUVE
40 KHRR
40.1  KHRR-DT
48 K48GX
58 KWBA
58.1  KWBA-DT
58.2  LATV

All the x.x channels are the new ATSC channels, rest are old NTSC most of
which, but not all, will be shut down in a year. For ATSC .1 is the primary
channel and .2, .3, etc are the sub channels.  The "#" on the remote could
be used for the "." In the channels.conf an ATSC next channel number would
look like:
:@13.1


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

Re: [vdr] sub channel numbering system

[Timothy D. Lenz]

Well, ".", "#", "*", something in the channels.conf. "0" is not  a valid
notation because 0 is part of the number system. 40 won't work for KVOA
because 40 is KHRR. And when displayed it should be "."

- Original Message - 
From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, March 06, 2008 1:49 AM
Subject: Re: [vdr] sub channel numbering system


> On 03/06/08 00:49, Timothy D. Lenz wrote:
> > Would it be possible to add support for the subchannel numbering system
used
> > with ATSC? Exmple of the channels in our area:
> >
> > 4   KVOA
> > 4.1KVOAD
> > 6   KUAT
> > 6.1KUATD1
> > 6.2KUATK
> > 6.3KUATV
> > 6.4KUATC
> > 9   KGUN
> > 9.1KGUND
> > 11 KMSB
> > 11.1  KMSBH
> > 13 KOLD
> > 13.1  KOLD-DT
> > 14 KUDF
> > 18 KTTU
> > 18.1  KTTUDT
> > 27 KUAS
> > 27.1  KUASHD
> > 34 KFTU
> > 38 KUVE
> > 40 KHRR
> > 40.1  KHRR-DT
> > 48 K48GX
> > 58 KWBA
> > 58.1  KWBA-DT
> > 58.2  LATV
> >
> > All the x.x channels are the new ATSC channels, rest are old NTSC most
of
> > which, but not all, will be shut down in a year. For ATSC .1 is the
primary
> > channel and .2, .3, etc are the sub channels.  The "#" on the remote
could
> > be used for the "." In the channels.conf an ATSC next channel number
would
> > look like:
> > :@13.1
>
> I don't like that dot notation.
>
> You could add a '0' to the old channels and leave out the '.', as in
>
> 40KVOA
> 41KVOAD
> 60KUAT
> 61KUATD1
> 62KUATK
> 63KUATV
> 64KUATC
> 90KGUN
> 91KGUND
>
> 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] sub channel numbering system

[Timothy D. Lenz]

Like it or not Sub channels are here to stay and the "." is the standard for
denoting a sub number. "vdr-1.5.15"

- Original Message - 
From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, March 06, 2008 1:49 AM
Subject: Re: [vdr] sub channel numbering system
>
> I don't like that dot notation.
>


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

Re: [vdr] sub channel numbering system

[Timothy D. Lenz]

That is something I brought up some time ago before I ran into the
sub-numbering. The Channels.conf has a way to group by provider, but right
now the only place to make use of it from in the program is while in live
video using the <> keys. If Provider grouping was expanded on then number
reuse would be solved.

(1)Confine channel selection to the current provider group would allow reuse
of numbers.

(2)Provide a way to more easly direct select providers. Remotes don't really
have a useable ascii keyboard, but they could be given numbers and their own
menu. Right now :@ denotes a channel, :abc denotes a
section/provider/whatever. Apply a version of the number system to the
provider grouping. If a number is not used, it starts counting from the last
used provider number. If no numbers where used, then it starts with 1 with 0
reservered for the provider guide. The new group entry would be :xx abc or
even :xxabc. basicly, if the first charator/s are digits, then they are a
user assigned number for that provider. If the Provders name starts with a
number, then just use a space, for example ": 1 abc".

Now start a number with "*" if you are changing providers and use "*0" for
the menu of providers which would work just like a menu for channels. Only
when switching to another provider it would land on the first channel in
that providers list.

(3)As for VDR relying on channel numbers being a problem for adding
subchannel suport. This is from the manual that is packed with VDR:

A particular channel can be uniquely identified by its channel ID,
which is a string that looks like this:

S19.2E-1-1089-12003-0

VDR already dosn't depend soly on channel numbers according to that.

- Original Message - 
From: "Theunis Potgieter" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, March 07, 2008 9:46 AM
Subject: Re: [vdr] sub channel numbering system


> So if provider 1 broadcasts  a 2.1 channel and provider 2 also
> broadcasts a 2.1 channel and you as a vdr user can have more than 1
> provider. What will the channel numbering scheme be for Provider 2?
> Will this introduce a bouqet in vdr?
>
> On 3/7/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 07, 2008 at 04:57:50PM +0100, Klaus Schmidinger wrote:
> > > On 03/07/08 16:31, VDR User wrote:
> > > > On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger


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

Re: [vdr] sub channel numbering system

[Timothy D. Lenz]

And that works to a point. I have been trying to pad using the sat number
for example 79, 97, 113, etc. But this makes the numbers a bit
long. The problem here is that some providers like to sprawl with there
numbers using 4 and sometimes even 5 digits. The 5 digit channel problem is
minor though as those seem to tend to be data channels with nothing on them.

- Original Message - 
From: "VDR User" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, March 07, 2008 9:53 AM
Subject: Re: [vdr] sub channel numbering system


> On Fri, Mar 7, 2008 at 8:46 AM, Theunis Potgieter
> <[EMAIL PROTECTED]> wrote:
> > So if provider 1 broadcasts  a 2.1 channel and provider 2 also
> >  broadcasts a 2.1 channel and you as a vdr user can have more than 1
> >  provider. What will the channel numbering scheme be for Provider 2?
> >  Will this introduce a bouqet in vdr?
>
> That problem already exists even without sub-channels and has never
> been officially addressed (to my knowledge).  The people I know
> dealing with this issue pad the channel numbers by adding a set
> number.  For example, if provider A and provider B both use -
> for their channel numbers, the user pads one of the providers by
> adding say 1 to the channel numbers thus having one provider
> retain -, and the other becoming 1-1.
>
> ___
> 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] sub channel numbering system

[Timothy D. Lenz]

>From what I have seen, the bigger providers start with 100. Smaller FTA
broadcasters seomtimes don't even number their channels and are assigned 0.
So for many of the channels, they just given the next free number paded with
the sat angle number. For OTA ATSC channels, if you live in/near a major
city or between 2 major citys, you will have a lot of channels and it is
much nicer if you can use the channel number assigned. Must people refer to
channels by the number and it is by the number that you select the channel.
If someone says there is somthing coming on channel 9 and don't sue the same
numbers, then you first have to figure out what channel 9 is, then find it
in your number system. The channel number has been the most common way to
refer to a local channel for decades.

- Original Message - 
From: "Alex Lasnier" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, March 07, 2008 10:47 AM
Subject: Re: [vdr] sub channel numbering system


> Timothy D. Lenz wrote:
> > Would it be possible to add support for the subchannel numbering system
used
> > with ATSC? Exmple of the channels in our area:
>
> Since VDR needs to be patched for ATSC anyway, I'll consider adding
> sub-channel support in the next ATSC patch. But my first impression is
> that such a change will likely be very ugly and break many things...
>
> However, none of the North American satellite providers have channel
> numbers lower than 50 (I think) so the easiest solution is to number
> your ATSC channels from 1 to 49. Is it really that important that your
> channel numbers match the broadcaster's?
>
>
>
>
>
>
> ___
> 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] sub channel numbering system

[Timothy D. Lenz]

The remotes that come with Nexus video cards have a telephone stile num pad
with both "*" and "#"

- Original Message - 
From: "Udo Richter" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, March 08, 2008 4:05 AM
Subject: Re: [vdr] sub channel numbering system


> Timothy D. Lenz wrote:
> > which, but not all, will be shut down in a year. For ATSC .1 is the
primary
> > channel and .2, .3, etc are the sub channels.  The "#" on the remote
could
> > be used for the "." In the channels.conf an ATSC next channel number
would
> > look like:
> > :@13.1
>
> Well, at least I've never seen any TV remote with a '.', '#' or '-' key
> on it. There wouldn't be a need for such a key here anyway.


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

Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?

[Timothy D. Lenz]

Bball posted on the DVBN forums that he got it working and it works good.
Has a few glitches that can be fixed with new firmware.

- Original Message - 
From: "Igor" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, March 15, 2008 3:22 AM
Subject: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?


> Hello
>
> is there any good news about the current status of Extension HD PCI from
ReelMultimedia ?
> Is there a full support for 1080p/1080i by hdmi and YUV output ?
> What about deinterlacing - is it work fine ?
>
> Igor
>
>
> ___
> 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] Extension HD PCI card from ReelMultimedia - what's new ?

[Timothy D. Lenz]

No idea. didn't know. I hope not.

- Original Message - 
From: "Manu Abraham" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, March 15, 2008 11:45 AM
Subject: Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?


> Timothy D. Lenz wrote:
> > Bball posted on the DVBN forums that he got it working and it works
good.
> > Has a few glitches that can be fixed with new firmware.
>
>
> Is this card still being manufactured, considering that Micronas USA
> closed down and the Decypher has been EOL'd ?
>
>
> Regards,
> Manu
>
> >
> > - Original Message - 
> > From: "Igor" <[EMAIL PROTECTED]>
> > To: "VDR Mailing List" 
> > Sent: Saturday, March 15, 2008 3:22 AM
> > Subject: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
> >
> >
> >> Hello
> >>
> >> is there any good news about the current status of Extension HD PCI
from
> > ReelMultimedia ?
> >> Is there a full support for 1080p/1080i by hdmi and YUV output ?
> >> What about deinterlacing - is it work fine ?
> >>
> >> Igor
> >>
> >>
> >> ___
> >> 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


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

Re: [vdr] VDR and "multiproto" - which driver to use?

[Timothy D. Lenz]

Cool, I was wondering how to locally merge branches. I have an ATSC card I'm
trying to get going that needs a  month old update that hasn't been merged
with anything yet last check: http://linuxtv.org/hg/~stoth/cx23885-video


- Original Message - 
From: "Manu Abraham" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, April 12, 2008 6:42 AM
Subject: Re: [vdr] VDR and "multiproto" - which driver to use?


> Klaus Schmidinger wrote:
> > I'm in the process of reintroducing the "multiproto" changes
> > in order to start the 1.7 developer version.
> >
> > Since I haven't been following the driver development recently
> > I was wondering if somebody could tell me which driver is best
> > to use at this time.
> >
> > The one at
> >
> > http://jusst.de/hg/multiproto
> >
> > is like 4 weeks old, while at
>
> Had been away on a vacation, plus some work, hence no recent changes.
>
> >
> > http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod
> >
> > there have been recent activities.
> > I'd like to switch to a driver that works with "multiproto" and
> > supports Oliver's full ts mod.
>
> It shouldn't be hard to use the 2 repositories together, it can be used
> quite straight forward like this:
>
> $ hg clone http://jusst.de/hg/multiproto
>
> $ cd multiproto
>
> $ hg pull -u http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod
>
> After the pull is complete, it will ask you to merge the heads:
>
> $ hg merge
>
> commit the merge
>
> $ hg commit
>
> You have both the functionality of both trees in one tree.
> If that looks hard, i can push a tree which is a result of the above
> outlined steps.
>
> Regards,
> Manu
>
>
> ___
> 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] Rotor patches

[Timothy D. Lenz]

There are 2 patches for the Rotor plugin:
vdr-1.5.5-rotor.diff
Rotor-0.1.4-vdr1.5.10.diff

They patch different areas. Are they both needed for vdr-1.6?

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

Re: [vdr] Rotor patches

[Timothy D. Lenz]

Strange, that patch fails on all hunks. looking to patch by hand, it's not
even close.  The vdr-1.5.5-rotor.diff patch applies.

- Original Message - 
From: "lucian orasanu" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 15, 2008 11:45 PM
Subject: [vdr] Rotor patches


> Hy.
>
> No, just Rotor-0.1.4-vdr1.5.10.diff.
>
> Lucian.
>
>
>


> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> ___
> 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] Rotor patches

[Timothy D. Lenz]

The vdr-1.5.5-rotor.diff patch comes with the newest version. the other
patch has been floating around on this group and the german board. Try
looking back in the archives here.

- Original Message - 
From: "Malcolm Caldwell" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 16, 2008 8:13 PM
Subject: Re: [vdr] Rotor patches


> On Wed, 2008-04-16 at 16:23 -0700, Timothy D. Lenz wrote:
> > Strange, that patch fails on all hunks. looking to patch by hand, it's
not
> > even close.  The vdr-1.5.5-rotor.diff patch applies.
>
> Where does one find these patches?
>
> >
> > - Original Message - 
> > From: "lucian orasanu" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Tuesday, April 15, 2008 11:45 PM
> > Subject: [vdr] Rotor patches
> >
> >
> > > Hy.
> > >
> > > No, just Rotor-0.1.4-vdr1.5.10.diff.
> > >
> > > Lucian.
> > >
> > >
> > >
> >

> > 
> > > Be a better friend, newshound, and
> > > know-it-all with Yahoo! Mobile.  Try it now.
> > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> > >
> > > ___
> > > 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


Rotor-0.1.4-vdr1.5.10.diff
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR and "multiproto" - which driver to use?

[Timothy D. Lenz]

- Original Message - 
From: "Manu Abraham" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, April 12, 2008 6:42 AM
Subject: Re: [vdr] VDR and "multiproto" - which driver to use?


> Klaus Schmidinger wrote:
> > I'm in the process of reintroducing the "multiproto" changes
> > in order to start the 1.7 developer version.
> >
> > Since I haven't been following the driver development recently
> > I was wondering if somebody could tell me which driver is best
> > to use at this time.
> >
> > The one at
> >
> > http://jusst.de/hg/multiproto
> >
> > is like 4 weeks old, while at
>
> Had been away on a vacation, plus some work, hence no recent changes.
>
> >
> > http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod
> >
> > there have been recent activities.
> > I'd like to switch to a driver that works with "multiproto" and
> > supports Oliver's full ts mod.
>
> It shouldn't be hard to use the 2 repositories together, it can be used
> quite straight forward like this:
>
> $ hg clone http://jusst.de/hg/multiproto
>
> $ cd multiproto
>
> $ hg pull -u http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod
>
> After the pull is complete, it will ask you to merge the heads:
>
> $ hg merge
>
> commit the merge
>
> $ hg commit
>
> You have both the functionality of both trees in one tree.
> If that looks hard, i can push a tree which is a result of the above
> outlined steps.
>
> Regards,
> Manu
>

Is the hg commit line only for sending the merge back to the source? because
when I tried t do a merge locally and got to that command, I got:

No username found, using '[EMAIL PROTECTED]' instead
transaction abort!
rollback completed

Yet the local tree seems to have kept the changes.


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

[vdr] No ac3 audio on Nexus

[Timothy D. Lenz]

I'm using linux 2.6.22.6 with v4l drivers. I'm using a Nexus for audio/video
out. I am trying to add an ATSC card and it seems atsc only sends ac3 audio.
So I have no audio on any of the channels. I tried connecting the ac3 audio
and I get audio out it with normal audio, But if I turn on "Use Dolby
display Digital" and select DD audio on a channel with DD, I loose audio on
both the ac3 channel and the normal audio ports. If I play a DVD it always
starts the dvd with normal audio and when I select ac3 audio goes out even
if I switch back to normal until I stop and restart the dvd. If I select one
of the other audio channels on the dvd, vdr totally locks up. This happens
with both vdr-1.5.10 and 1.6.0.


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

Re: [vdr] No ac3 audio on Nexus

[Timothy D. Lenz]

Yes it's a Nexus and yes I'm using the back connector from the card. I also 
tried the jack on the motherboard incase it was some how sending it there. I 
don't have any other audio software loaded so it should be just going to the 
nexus.
  - Original Message - 
  From: Pierre-Yves Paranthoen (PERSO) 
  To: vdr@linuxtv.org 
  Sent: Tuesday, April 22, 2008 11:16 PM
  Subject: [vdr] No ac3 audio on Nexus


  Do you use WinTV Nexus DVB-S from Hauppauge ? If yes, do you use the black 
coaxial digital output of the dvb-s card or the coax/spdif output of your 
mother card ?


--


  ___
  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 + ffmpeg? (h.264 problems)

[Timothy D. Lenz]

For h.264, might want to check this out:
http://code.google.com/p/coreavc-for-linux/
http://dvbn.happysat.org/viewtopic.php?t=44896&highlight=coreavc+vdr

- Original Message - 
From: "Reinhard Nissl" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, May 24, 2008 12:03 AM
Subject: Re: [vdr] VDR-xine + ffmpeg? (h.264 problems)


> Hi,
>
> Jelle De Loecker schrieb:
>
> > I followed a german tutorial on how to install VDR with xine. It had
> > some patches for better h.264 playback, but when I tune to BBC HD, it's
> > still painfully slow, and the image is quite bad, too!
>
> Try to cheat decoding in ~/.xine/config:
>
> video.processing.ffmpeg_choose_speed_over_accuracy:1
> video.processing.ffmpeg_pp_quality:0
> video.processing.ffmpeg_skip_loop_filter:all
> video.processing.ffmpeg_thread_count:2
>
> Regarding image quality: you'll have to use a deinterlacer
>
> xine ...
> -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame
_flag=0
>
> Using use_progressive_frame_flag=1 will disable the deinterlacer
> for progressive images automatically and save some CPU cycles but
> broadcasters often do not set this flag correctly in the images
> especially when there is only a little area with heavy movement
> (e. g. a football). Hence, those images do not get deinterlaced
> and look awfully.
>
> > I compiled xine with the ffmpeg option (external ffmpeg or something)
> > but I never installed ffmpeg nor are there any instructions on how to do
so.
>
> configure ; make ; make install
>
> > I mean, I could compile ffmpeg eventually, I just need to know if I need
> > to apply any more patches or so ...
> > I installed ffmpeg from the repository, but it doesn't seem to have any
> > effect.
>
> Optimize your FFmpeg for your hardware, e. g.
>
> ../ffmpeg/configure --prefix=/soft/ffmpeg-video --arch=i686
> --cpu=pentium4 --enable-pthreads --enable-shared --enable-gpl
> --enable-postproc --disable-stripping
>
> Similar optimization for xine-lib / xine-ui:
>
> CFLAGS='-g3 -O3 -pipe -march=pentium4' ../xine-lib-1.2/configure
> --prefix=/soft/xine-lib-1.2-video --with-external-ffmpeg
> --disable-dxr3
> CFLAGS='-g3 -O3 -pipe -march=pentium4' ../xine-ui/configure
> --prefix=/soft/xine-ui-1.2-video  --enable-vdr-keys
>
> Last but not least: make sure that you use a graphics board which
> supports hardware color space conversion and image scaling. Use
> an appropriate output driver, e. g.
>
> xine ... -V xv
>
> Bye.
> -- 
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> 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] [OT] Generic GPU-Accelerated Video Decoding

[Timothy D. Lenz]

Do you know about or are using: http://www.nvidia.com/object/cuda_home.html
?


- Original Message - 
From: "Gregoire Favre" <[EMAIL PROTECTED]>
To: 
Sent: Friday, June 06, 2008 1:51 AM
Subject: [vdr] [OT] Generic GPU-Accelerated Video Decoding


Hello,

just found out at
http://code.google.com/soc/2008/xorg/appinfo.html?csaid=ACD6AA025594454A
that :
"he purpose of this project is to produce a video decoding solution for
GPUs that are supported by the Gallium3D driver framework. The project
will attempt to implement the XvMC API using the programmable pipeline
of a typical GPU, thereby providing accelerated video decoding to a wide
variety of hardware. Since the decoding will be implemented using the
GPU's programmable pipeline, it is important to note that this solution
should support all recent GPUs regardless of whether or not they include
dedicated video decoding hardware. It is hoped that this GPU-based
acceleration will allow for real-time play back of HD video streams on
even modest hardware. The implementation will be developed and tested
using Gallium3D's SoftPipe driver, a stable software reference
implementation, and later Nvidia hardware and the Nouveau driver."

You can follow the progress at
http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml

Could be pretty usefull to lots of us :-)
-- 
Grégoire FAVRE  http://gregoire.favre.googlepages.com  http://www.gnupg.org
   http://picasaweb.google.com/Gregoire.Favre

___
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] dfb/coreavc,xine bulid problem

[Timothy D. Lenz]

I am runing debian 64bit. I am currently using rgb out of nexus But I want
to switch to the Matrox g450 so I can down convert hd to sd. I am trying to
use vdr-xine plugin, DirectFB with fb_xine for the matrox card  and coreavc
for decoder. The problem is getting xine 1.2 to build. Using latest HG make
seems to compile but using fakeroot dpkg-buildpackage I get a lot of this:

pp.c:309: warning: statement with no effect
pp.c:311: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
pp.c:312: error: implicit declaration of function âpp_postprocessâ
pp.c:316: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
pp.c:316: error: âpost_plugin_pp_tâ has no member named âpp_contextâ
pp.c:319: error: âpost_plugin_pp_tâ has no member named âlockâ
pp.c:319: warning: passing argument 1 of âpthread_mutex_unlockâ from
incompatible pointer type
pp.c:321: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
make[4]: *** [xineplug_post_planar_la-pp.lo] Error 1
make[4]: Leaving directory
`/usr/local/src/xine/xine-lib/master/xine-lib-1.2/src/post/planar'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/usr/local/src/xine/xine-lib/master/xine-lib-1.2/src/post'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/usr/local/src/xine/xine-lib/master/xine-lib-1.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/usr/local/src/xine/xine-lib/master/xine-lib-1.2'
make: *** [build-stamp] Error 2

And that is before trying to patch it with xine-lib-1.2hg-coreavc.diff. That
as 2 hunks fail which I patch by hand. The failed hunks are:

win32.c.rej
*** struct libs libraries[]={
*** 5063,5069 
  #else
  #define MANGLE(a) #a
  #endif
- static void ext_stubs(void)
  {
  // expects:
  //  ax  position index
--- 5288,5294 
  #else
  #define MANGLE(a) #a
  #endif
+ static WIN_BOOL WINAPI ext_stubs(void)
  {
  // expects:
  //  ax  position index

demux_ts.c.rej
***
*** 220,226 
ISO_13818_PART7_AUDIO = 0x0f, /* ISO/IEC 13818-7 Audio with ADTS
transport sytax */
ISO_14496_PART2_VIDEO = 0x10, /* ISO/IEC 14496-2 Visual (MPEG-4)
*/
ISO_14496_PART3_AUDIO = 0x11, /* ISO/IEC 14496-3 Audio with LATM
transport syntax */
-   ISO_14496_PART10_VIDEO = 0x1b /* ISO/IEC 14496-10 Video (MPEG-4
part 10/AVC, aka H.264) */
  } streamType;

  #define WRAP_THRESHOLD   27
--- 220,227 
ISO_13818_PART7_AUDIO = 0x0f, /* ISO/IEC 13818-7 Audio with ADTS
transport sytax */
ISO_14496_PART2_VIDEO = 0x10, /* ISO/IEC 14496-2 Visual (MPEG-4)
*/
ISO_14496_PART3_AUDIO = 0x11, /* ISO/IEC 14496-3 Audio with LATM
transport syntax */
+   ISO_14496_PART10_VIDEO = 0x1b,/* ISO/IEC 14496-10 Video (MPEG-4
part 10/AVC, aka H.264) */
+   STREAMDEV_H264_VIDEO = 0xe0   /* ISO/IEC 14496-10 Video (MPEG-4
part 10/AVC, aka H.264) */
  } streamType;

  #define WRAP_THRESHOLD   27

With the patches I get:

demux_ts.c:222: error: expected â,â or â}â before âSTREAM_VIDEO_MPEGâ
demux_ts.c: In function âdemux_ts_parse_pes_headerâ:
demux_ts.c:732: error: âSTREAM_AUDIO_AC3â undeclared (first use in this
function)
demux_ts.c:732: error: (Each undeclared identifier is reported only once
demux_ts.c:732: error: for each function it appears in.)
demux_ts.c:787: error: âSTREAM_VIDEO_MPEGâ undeclared (first use in this
function)
demux_ts.c: In function âdemux_ts_parse_pmtâ:
demux_ts.c:1331: error: âSTREAM_AUDIO_AC3â undeclared (first use in this
function)
make[3]: *** [demux_ts.lo] Error 1
make[3]: Leaving directory
`/usr/local/src/xine/xine-lib/xine-lib-1.2/src/demuxers'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/xine/xine-lib/xine-lib-1.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/xine/xine-lib/xine-lib-1.2'
make: *** [build-stamp] Error 2


The switches I add to the debian rule file are:

 --enable-directfb \
 --disable-dxr3 \
 --disable-xvmc \
 --without-x \
 --without-xcb \
 --disable-altivec \
 --disable-vis \

But I get the same errors with/out the switches.


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

Re: [vdr] dfb/coreavc,xine bulid problem

[Timothy D. Lenz]

>- Original Message - 
>From: "Darren Salt" <[EMAIL PROTECTED]>
>To: 
>Sent: Tuesday, June 10, 2008 3:13 PM
>Subject: Re: [vdr] dfb/coreavc,xine bulid problem


>I demand that Timothy D. Lenz may or may not have written...

>> I am runing debian 64bit.

>alpha? amd64? ia64? sparc? :-)

AMD Athlon64 x2 cpu.

>> I am currently using rgb out of nexus But I want to switch to the Matrox
>> g450 so I can down convert hd to sd. I am trying to use vdr-xine plugin,
>> DirectFB with fb_xine for the matrox card  and coreavc for decoder. The
>> problem is getting xine 1.2 to build. Using latest HG make seems to
compile
>> but using fakeroot dpkg-buildpackage I get a lot of this:

>> pp.c:309: warning: statement with no effect
>> pp.c:311: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
>> pp.c:312: error: implicit declaration of function âpp_postprocessâ
>[snip rest]

>Those errors don't make sense on their own. I'm guessing that there were
>errors before them...


gcc -DHAVE_CONFIG_H -I. -I../../../include -I../../.. -I../../../include -I.
./../../include -I../../../src -I../../../src/xine-engine -I../../../src/xin
e-engine -I../../../src/xine-utils -I../../../src/input -I../../../src/input
 -I../../../lib -I../../../lib -DNDEBUG -D_REENTRANT -DXINE_COMPILE -O3 -ffa
st-math -fexpensive-optimizations -fvisibility=hidden -pipe -Wall -Wformat=2
 -Wno-format-zero-length -Wmissing-format-attribute -Werror-implicit-functio
n-declaration -Wstrict-aliasing=2 -Wchar-subscripts -Wmissing-declarations -
Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g -march=athlon64 -g -M
T xineplug_post_planar_la-pp.lo -MD -MP -MF
.deps/xineplug_post_planar_la-pp.Tpo -c pp.c  -fPIC -DPIC -o
.libs/xineplug_post_planar_la-pp.o
pp.c:37:39: error: libpostproc/postprocess.h: No such file or directory
pp.c:61: error: âPP_QUALITY_MAXâ undeclared here (not in a function)
pp.c:81: error: expected specifier-qualifier-list before âpp_context_tâ
pp.c: In function âset_parametersâ:
pp.c:92: error: âpost_plugin_pp_tâ has no member named âlockâ
pp.c:92: warning: passing argument 1 of âpthread_mutex_lockâ from
incompatible pointer type
pp.c:96: error: âpost_plugin_pp_tâ has no member named âlockâ
pp.c:96: warning: passing argument 1 of âpthread_mutex_unlockâ from
incompatible pointer type
pp.c: In function âget_helpâ:
pp.c:124: error: âpp_helpâ undeclared (first use in this function)
pp.c:124: error: (Each undeclared identifier is reported only once
pp.c:124: error: for each function it appears in.)
pp.c:127: warning: format â%sâ expects type âchar *â, but argument 4 has
type âstruct xine_post_api_parameter_t *â
pp.c: In function âpp_init_pluginâ:
pp.c:157: warning: âxine_xmallocâ is deprecated (declared at
../../../include/xine/xineutils.h:606)
pp.c: In function âpp_open_pluginâ:
pp.c:194: error: âPP_FORMAT_420â undeclared (first use in this function)
pp.c:194: warning: assignment makes integer from pointer without a cast
pp.c:196: error: âPP_CPU_CAPS_MMXâ undeclared (first use in this function)
pp.c:196: error: invalid operands to binary |
pp.c:196: error: incompatible types in assignment
pp.c:196: warning: statement with no effect
pp.c:198: error: âPP_CPU_CAPS_MMX2â undeclared (first use in this function)
pp.c:198: error: invalid operands to binary |
pp.c:198: error: incompatible types in assignment
pp.c:198: warning: statement with no effect
pp.c:200: error: âPP_CPU_CAPS_3DNOWâ undeclared (first use in this function)
pp.c:200: error: invalid operands to binary |
pp.c:200: error: incompatible types in assignment
pp.c:200: warning: statement with no effect
pp.c:202: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
pp.c:202: warning: statement with no effect
pp.c:203: error: âpost_plugin_pp_tâ has no member named âpp_contextâ
pp.c:203: warning: statement with no effect
pp.c:205: error: âpost_plugin_pp_tâ has no member named âlockâ
pp.c:205: warning: passing argument 1 of âpthread_mutex_initâ from
incompatible pointer type
pp.c: In function âpp_disposeâ:
pp.c:232: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
pp.c:233: error: implicit declaration of function âpp_free_modeâ
pp.c:233: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
pp.c:234: error: âpost_plugin_pp_tâ has no member named âpp_modeâ
pp.c:234: warning: statement with no effect
pp.c:236: error: âpost_plugin_pp_tâ has no member named âpp_contextâ
pp.c:237: error: implicit declaration of function âpp_free_contextâ
pp.c:237: error: âpost_plugin_pp_tâ has no member named âpp_contextâ
pp.c:238: error: âpost_plugin_pp_tâ has no member named âpp_contextâ
pp.c:238: warning: statement with no effect
pp.c: In function âpp_drawâ:
pp.c:286: error: âpost_plugin_pp_tâ has no member named âlockâ
pp.c:286: warning: passing argument 1 of âpthread_mutex_lockâ from
incompatible pointer type
pp.c:288: error: âpost_plugin_pp_tâ has no member named âpp_contextâ
p

Re: [vdr] dfb/coreavc,xine bulid problem

[Timothy D. Lenz]

It's suposed to be a xine patch to use coreavc. Thought I listed it in th first 
post. 
xine-lib-1.2hg-coreavc.diff

- Original Message - 
From: "Goga777" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, June 15, 2008 1:59 PM
Subject: Re: [vdr] dfb/coreavc,xine bulid problem


> > I am runing debian 64bit. I am currently using rgb out of nexus But I want
> > to switch to the Matrox g450 so I can down convert hd to sd. I am trying to
> > use vdr-xine plugin, DirectFB with fb_xine for the matrox card  and coreavc
> > for decoder. 
> 
> which coreavc patch did you use ?
> 
> Goga
> 
> 
> 
> ___
> 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] dfb/coreavc,xine bulid problem

[Timothy D. Lenz]

That is the patch

- Original Message - 
From: "Goga777" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Monday, June 16, 2008 4:39 AM
Subject: Re: [vdr] dfb/coreavc,xine bulid problem


> do you mean xine-lib-1.2hg-coreavc.diff from Morfsta ?
> http://www.linuxtv.org/pipermail/vdr/2008-February/015744.html
> 
> 
> > It's suposed to be a xine patch to use coreavc. Thought I listed it in th 
> > first post. 
> > xine-lib-1.2hg-coreavc.diff
> > 
> > - Original Message - 
> > From: "Goga777" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Sunday, June 15, 2008 1:59 PM
> > Subject: Re: [vdr] dfb/coreavc,xine bulid problem
> > 
> > 
> > > > I am runing debian 64bit. I am currently using rgb out of nexus But I 
> > > > want
> > > > to switch to the Matrox g450 so I can down convert hd to sd. I am 
> > > > trying to
> > > > use vdr-xine plugin, DirectFB with fb_xine for the matrox card  and 
> > > > coreavc
> > > > for decoder. 
> > > 
> > > which coreavc patch did you use ?
> > > 
> > > Goga
> 
> 
> ___
> 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] new videocard from ATI with hardware decoding of HD video -UVD2

[Timothy D. Lenz]

ATI is not known for good driver support in Linux
- Original Message - 
From: "Goga777" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Monday, June 23, 2008 6:13 AM
Subject: [vdr] new videocard from ATI with hardware decoding of HD video -UVD2


> Hi
>
>
> AMD/ATI released new videocard HD4850 (RV770 processor) with new UVD2 - 
> unifed video decoder. There's good chanses for support
hdtv decoding video in Linux open source. BTW - in open radeon/xf86-video-ati 
driver there's support for this card
>
> http://www.phoronix.com/scan.php?page=article&item=amd_evolution&num=3
>
> Previously we shared that open-source UVD support may be unlikely for the 
> Radeon R600 series due to trouble sharing UVD
documentation without exposing the DRM (Digital Rights Management) coupled 
within this block. Future product generations may be of a
more modular design, but there's potentially good news surrounding the 
open-source UVD on the RV770. Its UVD2 design isn't modular,
but AMD's John Bridgman believes there may be a way to open up UVD2 without 
comprising their DRM obligations. Open-source
CrossFire/CrossFireX is also possible, but we'll save talking about that until 
the open-source developers have got more 3D work
tackled
>
>
>
>
>
> ___
> 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] Is any way to specify specific DVB-S card in channel.conf

[Timothy D. Lenz]

Email with the patch:
http://www.linuxtv.org/mailinglists/vdr/2004/12-2004/msg00647.html

- Original Message - 
From: "Ales Jurik" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Thursday, August 07, 2008 11:44 AM
Subject: Re: [vdr] Is any way to specify specific DVB-S card in channel.conf


> On Thursday 07 of August 2008, Vladimir Kangin wrote:
> > Dear All,
> >
> > Is any way to specify specific DVB-S card in channel.conf in a way that
> > some channels are sourced via /dev/dvb/adapter0 and other channels
> > sourced via /dev/dvb/adapter1
> >
> > Thanking in advance,
> > Vladimir Kangin
> 
> You should look for Sourcecap patch. I'm not using it so I don't know where 
> to 
> get it.
> 
> BR,
> 
> Ales
> 
> 
> ___
> 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] Is any way to specify specific DVB-S card in channel.conf

[Timothy D. Lenz]

So in your example:
...:0002,1702,1722,1801:...
Would retain the CA info but only try to use the second adapter to tune it? 
Does it matter where in the list it's placed?

- Original Message - 
From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 07, 2008 1:35 PM
Subject: Re: [vdr] Is any way to specify specific DVB-S card in channel.conf


> >> On Thursday 07 of August 2008, Vladimir Kangin wrote:
> >>> Dear All,
> >>>
> >>> Is any way to specify specific DVB-S card in channel.conf in a way that
> >>> some channels are sourced via /dev/dvb/adapter0 and other channels
> >>> sourced via /dev/dvb/adapter1
> 
> man 5 vdr:
> 
> SYNTAX
> CHANNELS
> ...
> Conditional access
>A hexadecimal integer defining how this channel can be 
> accessed:
> 
>  Free To Air
>0001...000F   explicitly requires the device with the given 
> number
>...
> 
> 
> 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] Is any way to specify specific DVB-S card in channel.conf

[Timothy D. Lenz]

And then there is the dishes, Some fixed, some not, some LNB's cove a different 
range that can over lap others in the set up meaning
not only do you need to be able to list tunners for channels, but provide a 
list of lnbs that can be used as well.
- Original Message - 
From: "VDR User" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Friday, August 08, 2008 9:37 AM
Subject: Re: [vdr] Is any way to specify specific DVB-S card in channel.conf


> On Thu, Aug 7, 2008 at 1:35 PM, Klaus Schmidinger
> <[EMAIL PROTECTED]> wrote:
> > man 5 vdr:
> >
> > SYNTAX
> >CHANNELS
> >...
> >Conditional access
> >   A hexadecimal integer defining how this channel can be 
> > accessed:
> >
> >     Free To Air
> >   0001...000F   explicitly requires the device with the given 
> > number
>
> If the device you need for that channel is the first device (device
> 0), then what?  Lotta guys have mixed setups these days.  Some cards
> can do certain modulations, some can't.  Some cards are dvb-s while
> some are dvb-s2.
>
> Cheers
>
> ___
> 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] Is any way to specify specific DVB-S card in channel.conf

[Timothy D. Lenz]

Will, assuming such things is a problem. With the mix of lnb types each limited 
in what they can get but often overlapping other
designs and a mix of tunners again covering different types of signals, You 
need to be able to match stuff up. In NA we have stuff
on c-band and ku, both linner and circular, dvb and dvb-s2 and sub veriants. 
Most anyone who has more then 1 dvb device has a mix of
devices and likly a mixed dish setup.


- Original Message - 
From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, August 16, 2008 3:18 AM
Subject: Re: [vdr] Is any way to specify specific DVB-S card in channel.conf


> On 08/08/08 06:35, Timothy D. Lenz wrote:
> > So in your example:
> > ...:0002,1702,1722,1801:...
> > Would retain the CA info but only try to use the second adapter to tune it? 
> > Does it matter where in the list it's placed?
>
> No. As it is right now, the CA field can either contain a device number
> or encryption systems.
>
> VDR normally assumes that every device can receive all sat positions
> (through a multiswitch), and automatically detects which device can
> decrypt a given encrypted channel.
>
> Klaus
>
> > - Original Message - 
> > From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Thursday, August 07, 2008 1:35 PM
> > Subject: Re: [vdr] Is any way to specify specific DVB-S card in channel.conf
> >
> >
> >>>> On Thursday 07 of August 2008, Vladimir Kangin wrote:
> >>>>> Dear All,
> >>>>>
> >>>>> Is any way to specify specific DVB-S card in channel.conf in a way that
> >>>>> some channels are sourced via /dev/dvb/adapter0 and other channels
> >>>>> sourced via /dev/dvb/adapter1
> >> man 5 vdr:
> >>
> >> SYNTAX
> >> CHANNELS
> >> ...
> >> Conditional access
> >>A hexadecimal integer defining how this channel can be 
> >> accessed:
> >>
> >>  Free To Air
> >>0001...000F   explicitly requires the device with the given 
> >> number
> >>...
> >>
> >>
> >> 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] iptv plugin - hardware scaling

[Timothy D. Lenz]

Could you post what enties/settings you used to get that working? I tried to 
get that working but didn't.
  - Original Message - 
  From: Hawes, Mark 
  To: vdr@linuxtv.org 
  Sent: Friday, August 22, 2008 4:05 AM
  Subject: [vdr] iptv plugin - hardware scaling


  Hi,

   

  I'm using iptv 0.2.1 with vdr  0.1.7 to view NASA TV on a technotrend ff card.

   

  The displayed picture occupies only the top left ¼ of the screen. My 
objective is to get it full screen.

   

  I have tried scaling it in the iptvscreen.sh script in the vlc call but this 
asks too much of the processor and things get very jerky.

   

  I believe that the ff card is capable of scaling in hardware. Any idea how I 
can get it to do this for an iptv stream?

   

  Thanks,

   

  Mark.






This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It 
is confidential to the ordinary user of the email address to which it was 
addressed and may contain copyright and/or legally privileged information. No 
one else may read, print, store, copy or forward all or any of it or its 
attachments. If you receive this email in error, please return to sender. Thank 
you.
 
If you do not wish to receive commercial email messages from Fujitsu 
Australia Limited, please email [EMAIL PROTECTED] 



--


  ___
  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] Greener VDR

[Timothy D. Lenz]

The main advantage to putting the "power off" button to use is to tell vdr you 
are not watching tv, so if it's also not recording,
it's free to tune to a TP with guide data or update channel list, etc..

- Original Message - 
From: "Dave P" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, September 06, 2008 3:40 AM
Subject: Re: [vdr] Greener VDR


> On Saturday 06 September 2008, [EMAIL PROTECTED] wrote:
>
> > I don't know how much watt savings could be achieved with this, but on
> > conseptual level it sounds good or do you agree?
> >
> > I hope some 10-20 watts could be saved in 1xFF and 2xbudget environment.
> > And less heat inside the box, on softdevices CPU runs lower power etc..
>
> I've taken measurements of power consumption on my vdr boxes. Both have had
> a single DVB-T budget card and playback is via the VOMP plugin.
>
> The present machine is a 2.3 GHz Athlon X2 64-bit. It idles at 42w,
> starting and stopping vdr has no measurable effect so I leave it running.
>
> The previous one used a 32-bit Athlon mobile CPU in a desktop motherboard.
> That machine idled at 62w (less efficient power supply and higher-spec
> graphics card). With vdr running the CPU temperature increased by 1 degree
> C and power consumption increased about 1 watt.
>
> It would be possible to save a few more watts if the DVB card could be
> completely powered off (my new machine needs only 38w without the card
> installed) but AFAIK that's not possible for PCI. A better bet for
> a 'green' vdr is careful choice of components.
> -- 
> Dave
>
> ___
> 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] Help building xine-lib-1.2 --with-external-ffmpeg

[Timothy D. Lenz]

  - Original Message - 
  From: Todd Luliak 
  To: vdr@linuxtv.org 
  Sent: Friday, September 12, 2008 7:42 AM
  Subject: [vdr] Help building xine-lib-1.2 --with-external-ffmpeg


  I've been running around in circles trying to get xine-lib-1.2 built with 
external ffmpeg. I currently use 1.2 with CoreAVC and would like to explore the 
h.264 improvements in ffmpeg trunk.
  I am suspecting my ffmpeg configuration/build/installation, but don't know 
what's wrong. 
  I have:
  Cleaned the libav* directories from /usr/local/include
  Pulled a current SVN of ffmpeg :
  URL: svn://svn.mplayerhq.hu/ffmpeg/trunk
  Repository Root: svn://svn.mplayerhq.hu/ffmpeg
  Repository UUID: 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b
  Revision: 15291

  ffmpeg configure:
  ./configure --arch=i686 --cpu=athlon64 --enable-gpl --enable-postproc 
--enable-pthreads --enable-liba52 --enable-libmp3lame --enable-libvorbis

  Builds sucessfully and the install places the following header directories in 
/usr/local/include:
  libavcodeclibavdevicelibavformat
  libavutillibpostproclibswscale

  Xine-lib 1.2 from HG:
  changeset:   10649:650d69296d66
  date:Fri Sep 05 18:02:23 2008 +0200

  configured with:
   ./autogen.sh --with-external-ffmpeg
  Nothing in this xine-lib has been patched yet (for vdr or CAVC) as I am 
trying to get the build 
  environment working properly before I mess with my CAVC patched version.

  Compile fails with:

   gcc -DHAVE_CONFIG_H -I. -I../../../include -I../../.. -I../../../include 
-I../../../include -I../../../src 
  -I../../../src/xine-engine -I../../../src/xine-engine 
-I../../../src/xine-utils -I../../../src/input -I../../../src/input 
-I../../../lib 
  -I../../../lib -I/usr/local/include -I/usr/local/include -I../../../src/dxr3 
-D_FILE_OFFSET_BITS=64 -DNDEBUG 
  -D_REENTRANT -DXINE_COMPILE -O3 -ffast-math -f expensive-optimizations 
-mtune=athlon 
  -fvisibility=hidden -pipe -Wall -Wformat=2 -Wno-format-zero-length 
-Wmissing-format-attribute 
  -Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts 
-Wmissing-declarations 
  -Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g -MT ffmpeg_decoder.lo 
-MD -MP -MF 
  .deps/ffmpeg_decoder.Tpo -c ffmpeg_decoder.c  -fPIC -DPIC -o 
.libs/ffmpeg_decoder.o
  mv -f .deps/ffmpeg_decoder.Tpo .deps/ffmpeg_decoder.Plo/bin/sh 
../../../libtool --tag=CC   
  --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I../../.. 
-I../../../include -I../../../include -I../../../src 
  -I../../../src/xine-engine -I../../../src/xine-engine 
-I../../../src/xine-utils  -I../../../src/input -I../../../src/input  
  -I../../../lib -I../../../lib  -I/usr/local/include   -I/usr/local/include
-I../../../src/dxr3 -D_FILE_OFFSET_BITS=64 
  -DNDEBUG -D_REENTRANT -DXINE_COMPILE  -O3  -ffast-math 
-fexpensive-optimizations  -mtune=athlon 
  -fvisibility=hidden-pipe  -Wall -Wformat=2 -Wno-format-zero-length 
-Wmissing-format-attribute 
  -Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts 
-Wmissing-declarations 
  -Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g  -MT 
ff_audio_decoder.lo -MD -MP -MF 
  .deps/ff_audio_decoder.Tpo -c -o ff_audio_decoder.lo ff_audio_decoder.c
   gcc -DHAVE_CONFIG_H -I. -I../../../include -I../../.. -I../../../include 
-I../../../include -I../../../src 
  -I../../../src/xine-engine -I../../../src/xine-engine 
-I../../../src/xine-utils -I../../../src/input -I../../../src/input
   -I../../../lib -I../../../lib -I/usr/local/include -I/usr/local/include 
-I../../../src/dxr3 -D_FILE_OFFSET_BITS=64 
  -DNDEBUG -D_REENTRANT -DXINE_COMPILE -O3 -ffast-math 
-fexpensive-optimizations -mtune=athlon 
  -fvisibility=hidden -pipe -Wall -Wformat=2 -Wno-format-zero-length 
-Wmissing-format-attribute 
  -Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts 
-Wmissing-declarations 
  -Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g -MT 
ff_audio_decoder.lo -MD -MP -MF 
  .deps/ff_audio_decoder.Tpo -c ff_audio_decoder.c  -fPIC -DPIC -o 
.libs/ff_audio_decoder.o

  ff_audio_decoder.c: In function 'ff_audio_decode_data':
  ff_audio_decoder.c:272: error: 'AVCodecContext' has no member named 
'bits_per_sample'
  ff_audio_decoder.c:325: error: implicit declaration of function 
'avcodec_decode_audio'
  ff_audio_decoder.c:330: error: 'AVCodecContext' has no member named 
'bits_per_sample'
  make[4]: *** [ff_audio_decoder.lo] Error 1
  make[4]: Leaving directory 
`/usr/local/src/newtest/xine-lib-1.2/src/combined/ffmpeg'
  make[3]: *** [all] Error 2
  make[3]: Leaving directory 
`/usr/local/src/newtest/xine-lib-1.2/src/combined/ffmpeg'
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory `/usr/local/src/newtest/xine-lib-1.2/src/combined'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/usr/local/src/newtest/xine-lib-1.2/src'
  make: *** [all-recursive] Error 1

  xine-lib compiles 

Re: [vdr] new reel hd pci-e card; vAti 2400 pro Mobility

[Timothy D. Lenz]

" Video acceleration for HDTV & blu ray
not full decoding.

- Original Message - 
From: "Torgeir Veimo" <[EMAIL PROTECTED]>
To: "VDR Mailing List" 
Sent: Saturday, September 27, 2008 1:29 AM
Subject: [vdr] new reel hd pci-e card; vAti 2400 pro Mobility


> There's a new reel HD pci-e card available, see
http://vdrportal.de/board/thread.php?threadid=80489&sid=ef2e2bfeb189c6808c2401b96e5bee98
>   and http://www.reel-multimedia.com/de/shop_extension_hd.php
>
> It's apparently an ATI  vAti 2400 pro Mobility card, and in the thread
> at vdrportal.de it's stated that linux drivers will follow in October.
>
> Does anyone know if this driver will support h.264 decoding in linux
> with this card?
>
> -- 
> Torgeir Veimo
> [EMAIL PROTECTED]
>
>
>
>
>
> ___
> 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] Soft RAID-5 + LVM file system corruption

[Timothy D. Lenz]

I started switching to raid but ran into problems with lack of info. 3 500gb 
sata drives with 3 partitions each. The first 2 are mirrored with 1 spare. That 
was to be for all the boot abd program files. The second was to be swap and the 
third which is raid 5 is storage for recordings. I have the recordings in use, 
but ran into some confusion about setting up the boot stuff. I don't recall the 
exact problem, but when installing the stuff for raid it did some kind of 
update, but only to the original kernal which is still there, not to the custom 
built which is being used. Some the messages pointed to things relating to 
using a ram disk during boot which is not suposed to be needed when just 
mirroring the boot area. 

I was going to also use LVM on the raid 5 part but ext3 wasn't well supported 
and the other file systems didn't have the full jernaling or something and I 
also want to set up samba and use some of that space for backing up my windows 
computer.

  - Original Message - 
  From: Alex Betis 
  To: vdr@linuxtv.org 
  Sent: Thursday, December 18, 2008 12:51 PM
  Subject: [vdr] Soft RAID-5 + LVM file system corruption


  Hello all,

  A system question, not so VDR related, but I hope someone in the list use the 
same configuration.

  From time to time my system won't boot since ext3 file system got corrupted 
and asks me to log in as root and run fsck manually. No bad blocks are found, 
just incorrectly stored nodes that are always fixed.

  I have 3 320GByte SATA disks partitioned to several large partitions, those 
partitions are configured to software RAID-5 between disks and on those RAID-5 
partitions there are 2 LVM volumes, one for system and another for storage.
  There are also 250 MByte partition on every disk, while 2 of them are 
configured to software RAID-1 and mapped to /boot.

  System LVM gets corrupted more often since its used more intensively.

  Does anybody here have the same configuration? Or any other software RAID-5 
configuration?
  Did anyone faced such problems? Maybe someone facing the same problem without 
RAIDs?
  Any help will be appreciated.

  I'm running on Fedora 10 with 2.6.27 kernel.
  I had the same problem with Fedora 8 as well.

  Thanks.
  Alex.




--


  ___
  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] Soft RAID-5 + LVM file system corruption

[Timothy D. Lenz]

Debian
  - Original Message - 
  From: Alex Betis 
  To: VDR Mailing List 
  Sent: Thursday, December 18, 2008 2:32 PM
  Subject: Re: [vdr] Soft RAID-5 + LVM file system corruption





  On Thu, Dec 18, 2008 at 11:20 PM, Timothy D. Lenz  wrote:

I started switching to raid but ran into problems with lack of info. 3 
500gb sata drives with 3 partitions each. The first 2 are mirrored with 1 
spare. That was to be for all the boot abd program files. The second was to be 
swap and the third which is raid 5 is storage for recordings. I have the 
recordings in use, but ran into some confusion about setting up the boot stuff. 
I don't recall the exact problem, but when installing the stuff for raid it did 
some kind of update, but only to the original kernal which is still there, not 
to the custom built which is being used. Some the messages pointed to things 
relating to using a ram disk during boot which is not suposed to be needed when 
just mirroring the boot area. 

I was going to also use LVM on the raid 5 part but ext3 wasn't well 
supported and the other file systems didn't have the full jernaling or 
something and I also want to set up samba and use some of that space for 
backing up my windows computer.
  What distro did you tried to use?
  I've tried Ubuntu about a year ago, but it didn't support any RAID nor LVM 
configurations in installation stage, so I went back to Fedora, which has all 
those options.

  Configuration is very easily done. The only tricky part is that you have to 
type some commands manually in fdisk to install MBR on both disks if you want 
to boot from RAID-1 setup.
  All the info is available on the net.

  By the way, my swap is also on LVM/RAID-5.

  I just don't know how to get rid from the node corruptions.
  I start suspecting my hardware. Run memory tests many times, but no 
conclusion so far.



  - Original Message - 
  From: Alex Betis 
  To: vdr@linuxtv.org 
  Sent: Thursday, December 18, 2008 12:51 PM
  Subject: [vdr] Soft RAID-5 + LVM file system corruption


  Hello all,

  A system question, not so VDR related, but I hope someone in the list use 
the same configuration.

  From time to time my system won't boot since ext3 file system got 
corrupted and asks me to log in as root and run fsck manually. No bad blocks 
are found, just incorrectly stored nodes that are always fixed.

  I have 3 320GByte SATA disks partitioned to several large partitions, 
those partitions are configured to software RAID-5 between disks and on those 
RAID-5 partitions there are 2 LVM volumes, one for system and another for 
storage.
  There are also 250 MByte partition on every disk, while 2 of them are 
configured to software RAID-1 and mapped to /boot.

  System LVM gets corrupted more often since its used more intensively.

  Does anybody here have the same configuration? Or any other software 
RAID-5 configuration?
  Did anyone faced such problems? Maybe someone facing the same problem 
without RAIDs?
  Any help will be appreciated.

  I'm running on Fedora 10 with 2.6.27 kernel.
  I had the same problem with Fedora 8 as well.

  Thanks.
  Alex.




--


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

Re: [vdr] Frames per second PAL vs. NTSC

[Timothy D. Lenz]

Maybe these links will help:

http://cnyack.homestead.com/files/modulation/ntsc_sig.htm
http://en.wikipedia.org/wiki/Frame_rate
http://en.wikipedia.org/wiki/NTSC
http://www.afterdawn.com/glossary/terms/ntsc.cfm
http://www.fixya.com/support/t174610-ntsc_frame_rate_29_97_hz

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Monday, January 05, 2009 3:31 AM
Subject: [vdr] Frames per second PAL vs. NTSC


> In order to correctly handle the progress indicator for NTSC
> recordings I'm now determining the frame rate from the
> actual data. With PAL's 25 frames per second the distance
> between two frames is 3600 "ticks" of 1/9s. With NTSC
> this number is 3003, which results in 29.97002997003 fps.
> Is NTSC's frame rate really that "odd"? I thought it would
> be an even 30 fps.
> 
> 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] [OT] development infrastructur for VGA2SCART patch set

[Timothy D. Lenz]

First, I don't know why, but everyone of your post comes through as a text 
attachment which has to be saved out to be read. Others
on the list come through normal.

When puting just a few parts in a connector I try  to solder the parts directly 
to the pins on the back of the connector in a way
that allows the shell to still fit. If there are too many parts or wires that 
need to be connect to allow this and still keep the
parts ridged, then a small perf  board should be used. In eather case, make use 
of very small heat swrink to prevent shorts.

I also use hot melt glue to hold parts and wires in place and reduce strain. If 
the factory shell can not be used, then I mold the
area with hot melt. Once you have a solid mass that covers all bare wires, you 
can shape i with a soldering iron. With very little
practice you can smooth the glue to look like it was molded on. Then heat 
swrink tubing can be used to cover it and make it look
nice. If you have a soldering iron with adjustable temp, keep it low for 
shaping. If you latter need to work on it, you can remove
the glue with a dental pick with a bit of work.

- Original Message - 
From: "Paul Menzel" 
To: 
Sent: Wednesday, March 04, 2009 10:32 AM
Subject: Re: [vdr] [OT] development infrastructur for VGA2SCART patch set


> ___
> 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] [OT] development infrastructur for VGA2SCART patch set

[Timothy D. Lenz]

Same thing, just attachments. And I turn off a lot of the fancy crap in mail 
programs to reduce the chance of them running some
virus attached to the mail. Mail should be text and any code should be limited 
to files that are in no way run by the mail program.
Some things are just ment to be seen or read, not run. If ms woke up to that 
fact, there be a lot less ways to infect computers.

- Original Message - 
From: "Darren Salt" 
To: 
Sent: Wednesday, March 04, 2009 4:43 PM
Subject: Re: [vdr] [OT] development infrastructur for VGA2SCART patch set


> ___
> 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] /tmp/VDRBOOT_COMPLETE

[Timothy D. Lenz]

In the startup scripts I've been using for some time, it does a check for
/tmp/VDRBOOT_COMPLETE
to confirm vdr started correctly. It doesn't seem to have a problem if the file 
is not found, but somewhere along the line vdr
stoped creating this file on startup. What is the current way to check if vdr 
correctly started?


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

[vdr] Problems with atsc video and channel scaning

[Timothy D. Lenz]

Setting up a new system, with vdr-1.7.5, xine-vdpau r260 and vdr-xine plugin 
using a FusionHDTV7 dual express. Video card is
en8400gs silent.

First, when I have an HD stream ether live or recorded it get high frame 
droping:

video_out: throwing away image with pts 24715684 because it's too old (diff : 
3402).
video_out: throwing away image with pts 24727696 because it's too old (diff : 
4065).
video_out: throwing away image with pts 24736705 because it's too old (diff : 
3566).
video_out: throwing away image with pts 24748717 because it's too old (diff : 
4229).

If I turn off deinterlacing the drops stop but the picture is then distorted 
around moving/changing objects. vdpau does seem to be
active and cpu usage is low.

I also saw a problem with it start loosing signal and then vdr would lock up. I 
found the card was getting hot. I put a small fan in
the case above the card.

Another problem I'm seeing is, using the atscepg plugin when I try to scan for 
channels, it finds none even though I can tune all of
the ones I know about. i did use vdr-1.7.2-atsc-0.0.3.diff


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

Re: [vdr] vdr and vdpau

[Timothy D. Lenz]

This is not correct. I am having problems with droped frames on atsc hd and I 
turned off speed scaling so both cores would stay at
2.6ghz. It had NO EFFECT.

- Original Message - 
From: "Gerald Dachs" 
To: 
Sent: Monday, April 27, 2009 3:35 PM
Subject: Re: [vdr] vdr and vdpau


> > I have improvement with HD channels cpu utilization wise but still
> > choppy image.
> >
> > Do I need to patch vdr itself or change some config options to
> > optimize the speed?
>
> Don't let the powernowd or the cpufreqd clock down your CPU. With the
> current Nvidia-Driver you need at least 2GHz clock speed with your AMD CPU.
> The onboard graphic needs the memory controller inside the cpu to access
> the memory and it seem it is not fast enough if the CPU is clocked down.
> For less power consumption you could undervolt your CPU instead.
>
> More Informations you can get in the http://vdr-portal.de. VDPAU is a
> hot topic there.
>
> 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

[vdr] ATSC with xine-vdpau frame drops

[Timothy D. Lenz]

I havd vdr-1.7.5, xine-vdpau r260, vdr-xine .91. Runing on a Athlon64 x2 and 
Asus en8400gs silent video card. I have a FusionHDTV7
Dual Express in it currently. I am having problems figureing out the proper 
settings in all the config files. I am getting droped
frames, sometimes high enough to cause the popup box. Does it with any of the 
deint options.

I will be setting up two systems basicly the same. One will be going to the HD 
input on a MITS WS65905 an dthe other will be going
through the RGB inputs on a pre-HD (1984) Sony. Currently I just have both 
ports going to standard computer monitors.  The DVI port
seems to want to run at 85hz while the VGA is runing at 60hz. id on't know if 
the high rate on the one is part of the problem.

/etc/X11/xorg.conf has
Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Unknown"
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"
EndSection

Section "Device"
Identifier  "GeForce 8400GS"
Driver  "nvidia"
VendorName "NVIDIA Corporation"
Option  "TwinView"  "true"
Option  "TwinViewOrientation"   "Clone"
#Option  "TVOutFormat"   "COMPOSITE"
Option  "TVStandard""NTSC-M"
Option  "TVOverScan""0.5"
#   Option  "TVDeflicker"   "0"
Option  "SecondMonitorHorizSync""30-50"
Option  "SecondMonitorVerRefresh"   "59.94"
#   Option  "MetaModes" 
"1024x768,1024x768;800x600,800x600;640x480,640x480;512x384,512x384"
#Option  "MetaModes" "800x600,800x600;640x480,640x480"
EndSection

Section "Screen"
Identifier "Screen0"
Device "GeForce 8400GS"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
   Viewport0 0
Depth   24
Modes  "1024x768" "800x600" "640x480"
EndSubSection
EndSection


I don't seem to have any nvidia setings file but I was able to get a dump of 
what it is using.

  Attribute 'RefreshRate' (LLLx64-32:0.0; display device: CRT-0): 85.00 Hz.
'RefreshRate' is an integer attribute.
'RefreshRate' is a read-only attribute.
'RefreshRate' is display device specific.
'RefreshRate' can use the following target types: X Screen, GPU.

  Attribute 'RefreshRate' (LLLx64-32:0.0; display device: CRT-1): 60.00 Hz.
'RefreshRate' is an integer attribute.
'RefreshRate' is a read-only attribute.
'RefreshRate' is display device specific.
'RefreshRate' can use the following target types: X Screen, GPU.

  Attribute 'RefreshRate3' (LLLx64-32:0.0; display device: CRT-0): 84.997 Hz.
'RefreshRate3' is an integer attribute.
'RefreshRate3' is a read-only attribute.
'RefreshRate3' is display device specific.
'RefreshRate3' can use the following target types: X Screen, GPU.

  Attribute 'RefreshRate3' (LLLx64-32:0.0; display device: CRT-1): 60.004 Hz.
'RefreshRate3' is an integer attribute.
'RefreshRate3' is a read-only attribute.
'RefreshRate3' is display device specific.
'RefreshRate3' can use the following target types: X Screen, GPU.
---

I have also had what seme to be video lockups. First I thought it was the 
tunner over heating because when it first happened, vdr
would not respond to remote and the card was hot. I added heat sinks to the 3 
main chips with thermal tape and put an 80mm fan over
the card. It is now midly warm but video still locks at times. I can run all 
night or it can lock within an hour. There are a lot of
lines like this in syslog and user.log:

Apr 30 15:52:49 LLLx64-32 vdr: [19935] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
Apr 30 15:52:49 LLLx64-32 vdr: [19935] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=eng:0:0
Apr 30 15:52:49 LLLx64-32 vdr: [19935] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
Apr 30 15:53:09 LLLx64-32 vdr: [19935] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0

Apr 30 15:00:17 LLLx64-32 vdr: [8107] TS continuity error (8)
Apr 30 15:00:17 LLLx64-32 vdr: [8107] TS continuity error (0)
Apr 30 15:00:17 LLLx64-32 vdr: [8107] TS continuity error (3)
Apr 30 15:00:17 LLLx64-32 vdr: [8107] TS continuity error (6)
Apr 30 15:00:17 LLLx64-32 vdr: [8107] TS continuity error (12)



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

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

[Timothy D. Lenz]

I just got an updated v4l today because it has fixes for xc5000 based cards as 
of monday along with new firmware for that card. I
also use nexus and the first patch below seems to now be included, but the 
second patch uas a lot of both succeeded and failed:

patching file linux/drivers/media/dvb/ttpci/av7110.h
patching file linux/drivers/media/dvb/ttpci/av7110_av.c
Hunk #2 succeeded at 972 (offset 3 lines).
Hunk #3 succeeded at 985 (offset 3 lines).
Hunk #4 succeeded at 1022 (offset 3 lines).
Hunk #5 succeeded at 1034 (offset 3 lines).
Hunk #6 succeeded at 1128 (offset 3 lines).
Hunk #7 succeeded at 1140 (offset 3 lines).
Hunk #8 FAILED at 1153.
Hunk #9 succeeded at 1168 (offset 2 lines).
Hunk #10 succeeded at 1180 (offset 2 lines).
Hunk #11 succeeded at 1258 (offset -2 lines).
Hunk #12 succeeded at 1273 with fuzz 2 (offset -2 lines).
Hunk #13 FAILED at 1321.
Hunk #14 succeeded at 1347 (offset -2 lines).
Hunk #15 succeeded at 1357 (offset -2 lines).
Hunk #16 succeeded at 1371 (offset -2 lines).
Hunk #17 FAILED at 1469.
Hunk #18 FAILED at 1480.
4 out of 18 hunks FAILED -- saving rejects to file 
linux/drivers/media/dvb/ttpci/av7110_av.c.rej

Is it still needed or has it been replaced with another patch?

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Sunday, April 12, 2009 2:39 AM
Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.5


IMPORTANT:
==

You need the DVB driver version from

  http://linuxtv.org/hg/~endriss/v4l-dvb

or, alternatively, apply the two patches

  http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/55fa4f709cf2
  http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/b5567f27fba7

(in *this* sequence) in order to replay TS recordings with full featured
DVB cards! The second patch is only required for replaying pure audio
recordings.
Users of full featured DVB cards also need to use a new firmware,
available at

  http://www.escape-edv.de/endriss/firmware

Note that the header files in the latest driver versions may be broken.
If you get compiler error messages like

  /usr/include/sys/types.h:52: error: conflicting declaration 'typedef 
__ino64_t ino_t'
  /usr/include/linux/types.h:14: error: 'ino_t' has a previous declaration as 
'typedef __kernel_ino_t ino_t'

when compiling VDR, you need to put the driver header files back to
how they were before they got broken. One way of doing this is to
apply the patch from

  ftp://ftp.cadsoft.de/vdr/Developer/v4l-dvb-header-fix.diff

(I'm not claiming that this is the right way to fix this, since the driver
developers may have had good reasons for making that change. However, both
the driver and VDR compile and work fine with this).


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

Re: [vdr] Truecolor osd and speed.

[Timothy D. Lenz]

What about a simple Option flag? TrueColor yes/no/auto.  A setting in the 
config file with auto detecting if output is via a nexus
or other device that can do TC. If auto detect is not possible then just yes/no.

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Saturday, June 13, 2009 9:49 AM
Subject: Re: [vdr] Truecolor osd and speed.


> On 06/13/09 18:34, Udo Richter wrote:
> > On 13.06.2009 17:31, VDR User wrote:
> >> "VDR renders its OSD into an array (of 8 bit indexes into a palette right
> >> now, and of full 24(rgb)+8(alpha) bit color values for truecolor)
> >> and its up to the device implementation how it transfers that array (or
> >> parts of it) to the actual display hard- or software."
> >
> > To keep compatibility and to be less limited for a new OSD architecture,
> > I would strongly suggest to keep the current OSD as it is, and introduce
> > a secondary OSD2 interface for true color display.
>
> The interfaces of cOsd all use a 32 bit tColor, which is perfectly
> suited to support true color. The underlying palette/bitmap stuff
> is only necessary for the "old" OSD types, while new ones will just
> use one big array of tColor values.
> I see no need for an OSD2 interface - the current interface (maybe with
> a few touchups and extensions, like the scrolling API) should do just
> fine, with full backwards compatibility.
>
> >  From the performance point of view, would it be possible to directly
> > render OSD into the graphics memory instead of copying an (possibly
> > 1920x1200x32 = 9Mb) memory OSD to the surface?
>
> I'm often told how simple it is for "modern hardware" to decode
> h.264 in software - I would assume that copying a 9MB block of data
> should be peanuts for such hardware ;-) Besides, most of the time
> (especially with the proposed scrolling API) it wouldn't even
> have to copy the entire block - only those parts that have
> actually changed, just like it's done already in the current OSD.
>
> Of course a particular derived cOsd object can render its data
> in whatever way it pleases.
>
> 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

[vdr] Hulu on vdr?

[Timothy D. Lenz]

Anyone able to come up with a plugin or way to use hulu with vdr? Maybe 
browsing their site from another computer going through
vdradmin and then when selecting a show, vdradmin could send the url to vdr 
through the iptv plugin?


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

Re: [vdr] [patch] optimize device selection

[Timothy D. Lenz]

I don't yet know if this patch is the cause, but I have a setup I am working on 
which has a FusionHDTV7 dual express and after it
has been running for a few days, vdr seems to loose contact with the second 
tunner. When selecting other channels using vdradmin and
then going back to the channel it had been left on for awhile, I get the xine 
no signal screen. Switching to any other channel
works. Using femon I switch tunners while on the channel that no longer works 
and it starts working. I can go to any channel and
swith between the tunners and only get video on the first tunner. The problem 
may be triggered by recording but sure. The amount of
time to pass for it to show changes.

Using vdr-1.7.8

First I thought it was the driver crashing. So I tried restarting vdr, but not 
the drivers and that got the second tunner back.

- Original Message - 
From: "jlacvdr" 
To: "VDR Mailing List" 
Sent: Sunday, May 10, 2009 10:35 AM
Subject: [vdr] [patch] optimize device selection


> Hi,
>
> This patch is for vdr users's which have several cards.
>
> He changes the device selection, by adding two factors in the 'impact' choice 
> :
> - prefering a already tuned device
> - the last usage time of device
>
> So, all devices are used and zapping time is reduce.
>
> Works better when eitscanner is disable.
>
> Regards,
>
> JLac
>





> ___
> 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] Turn off/relocate ts error logging

[Timothy D. Lenz]

My log files get so big it,s very hard to check them because of the ts error 
messages that get flooded to it. I've had logs near 2gb
in size. I have a problem with xine crashing when there is a weak signal and 
the ts loging bloating the log files is creating a lot
of problems. Need a way to turn off ts error loging or relocate to another file.


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

Re: [vdr] Turn off/relocate ts error logging

[Timothy D. Lenz]

Form /var/log/user.log:

Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (2)
Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (6)
Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (9)
Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (11)
Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (8)

But in looking at the log now with it having run a bit with good signal, I find 
another log spam:

Aug 23 10:44:18 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=eng,72=eng:0:0
Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=spa,72=spa:0:0
Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng,88=eng:0:0
Aug 23 10:45:21 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
Aug 23 10:45:42 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;50=eng:0:0
Aug 23 10:45:42 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;66=spa:0:0
Aug 23 10:46:03 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
Aug 23 10:46:03 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
Aug 23 10:46:24 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:46:24 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=eng:0:0
Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
Aug 23 10:47:06 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 17+17=2:0;20=eng:0:0
Aug 23 10:47:27 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:47:48 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=eng,72=eng:0:0
Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
Aug 23 10:48:30 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
Aug 23 10:48:30 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=spa,72=spa:0:0
Aug 23 10:48:30 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng,88=eng:0:0
Aug 23 10:48:51 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
Aug 23 10:49:12 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;50=eng:0:0
Aug 23 10:49:12 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;66=spa:0:0
Aug 23 10:49:33 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
Aug 23 10:49:33 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
Aug 23 10:49:54 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:49:54 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
Aug 23 10:50:16 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
Aug 23 10:50:16 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 65+65=2:0;68=eng:0:0
Aug 23 10:50:16 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
Aug 23 10:50:36 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
0+0=0:0:0:0 to 17+17=2:0;20=eng:0:0


Don't know if that is VDR or something the atsc plugin is causing.

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Sunday, August 23, 2009 2:15 AM
Subject: Re: [vdr] Turn off/relocate ts error logging


> On 22.08.2009 19:12, Timothy D. Lenz wrote:
> > My log files get so big it,s very hard to check them because of the ts 
> > error messages that get flooded to it. I've had logs near
2gb
> > in size. I have a problem with xine crashing when there is a weak signa

Re: [vdr] HD clients for vdr

[Timothy D. Lenz]

I've had a problem with seeminly under powered video card using a 8400gs (g98) 
and little by little am finding out what settings are
needed:

gui.dropped_frames_warning:0

# vdpau: HD deinterlace method
# { bob  half temporal  half temporal_spatial  temporal  temporal_spatial }, 
default: 3
#video.output.vdpau_deinterlace_method:temporal

# vdpau: Try to recreate progressive frames from pulldown material
# bool, default: 1
video.output.vdpau_enable_inverse_telecine:0

# vdpau: disable deinterlacing when progressive_frame flag is set
# bool, default: 0
video.output.vdpau_honor_progressive:1

# vdpau: disable advanced deinterlacers chroma filter
# bool, default: 0
video.output.vdpau_skip_chroma_deinterlace:1

# number of audio buffers
# numeric, default: 230
engine.buffers.audio_num_buffers:500

# number of video buffers
# numeric, default: 500
engine.buffers.video_num_buffers:1000

# default number of video frames
# numeric, default: 15
engine.buffers.video_num_frames:22


Turning off the droped frame warnings stops it from poping up the box with it 
floods droped frames. Don't need a popup telling you
you are droping frames when you have freeze frame video

- Original Message - 
From: 
To: 
Sent: Sunday, August 23, 2009 9:24 AM
Subject: Re: [vdr] HD clients for vdr


> >Yes, it has limitations but given the low power consumption it's still
> >impressive. The ION runs fine with advanced deinterlacer for 576i and
> >temporal for 1080i. A 9500GT can do advanced on 1080i but for me it's not
> >worth the extra heat and space. I have the computer on the back of my TV.
> >http://www.minhembio.com/magho
> >/Magnus
>
> Are you sure your ION can play 1080i with temporal? What is the source? I
> have tried a lot of HD-channels on Thor 0.8W without success and I have to
> use bob deinterlace filter or else the hardware drops frames.
>
> See:
> http://www.nvnews.net/vbulletin/showthread.php?t=136326&highlight=deinterlace
>
> I have installed Ubuntu 9.04 amd64 server with a minimum of services.
>
> /Svankan
>
>
> ___
> 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] HD clients for vdr

[Timothy D. Lenz]

Well, "video.output.vdpau_enable_inverse_telecine:1" is the one that stoped the 
problem with it freezing and then runing fast
forward. The buffer settings help reduce droped frames as does the chroma 
setting, though it's not a big impact and I see no change
in video quality. Having it deint chroma doesn't seem to have any effect other 
then eat a few more gpu cycles.

 video.output.vdpau_honor_progressive:1 simply turns off deint if you have a 
progressive video. No need to deint was isn't. I do
know that as per other recomendations I had the video buffers up around 1 
and audio down at 5 for awhile and I had more droped
frames with high buffer setting. I could only use bob and the inverse_telecine 
setting is only for spectral.

- Original Message - 
From: "VDR User" 
To: "VDR Mailing List" 
Sent: Sunday, August 23, 2009 11:34 AM
Subject: Re: [vdr] HD clients for vdr


> On Sun, Aug 23, 2009 at 11:12 AM, Timothy D. Lenz wrote:
> > I've had a problem with seeminly under powered video card using a 8400gs 
> > (g98) and little by little am finding out what settings
are
> > needed:
> >
> > # vdpau: Try to recreate progressive frames from pulldown material
> > # bool, default: 1
> > video.output.vdpau_enable_inverse_telecine:0
> >
> > # vdpau: disable deinterlacing when progressive_frame flag is set
> > # bool, default: 0
> > video.output.vdpau_honor_progressive:1
> >
> > # vdpau: disable advanced deinterlacers chroma filter
> > # bool, default: 0
> > video.output.vdpau_skip_chroma_deinterlace:1
> >
> > # number of audio buffers
> > # numeric, default: 230
> > engine.buffers.audio_num_buffers:500
> >
> > # number of video buffers
> > # numeric, default: 500
> > engine.buffers.video_num_buffers:1000
>
> I use an 8400gs in two boxes and I don't get freezing video.  However,
> my settings are different.  I didn't have to change the values for the
> following, they work by default:
>
> video.output.vdpau_enable_inverse_telecine:1
> video.output.vdpau_honor_progressive:0
> video.output.vdpau_skip_chroma_deinterlace:0
> engine.buffers.audio_num_buffers:230
> engine.buffers.video_num_buffers:500
>
> ___
> 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] HD clients for vdr

[Timothy D. Lenz]

Some stations do 1080i others do 720p. The 1080i seem to be worse but then I 
turn of deint for progressive video which should free
up some of the video card.

- Original Message - 
From: "Goga777" 
To: 
Sent: Sunday, August 23, 2009 11:45 AM
Subject: Re: [vdr] HD clients for vdr


> > I use an 8400gs in two boxes and I don't get freezing video.
>
> do you mean 1080i video ?
> which deinterlaicer are you using ?
>
> > my settings are different.  I didn't have to change the values for the
> > following, they work by default:
> >
> > video.output.vdpau_enable_inverse_telecine:1
> > video.output.vdpau_honor_progressive:0
> > video.output.vdpau_skip_chroma_deinterlace:0
> > engine.buffers.audio_num_buffers:230
> > engine.buffers.video_num_buffers:500
>
> ___
> 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] Turn off/relocate ts error logging

[Timothy D. Lenz]

This is my complete channels.conf file:
:@1041
KVOA-DT,KVOA-DT:527028615:B6M10:T:0:49=2:0;52:0:0:3:0:211:0
:@1061
PBS HD,PBS HD:569028615:B6M10:T:0:49=2:0;52,56:0:0:1:0:213:0
:@1062
V-Me,V-Me:569028615:B6M10:T:0:65=2:0;68,72:0:0:2:0:213:0
:@1063
CREATE,CREATE:569028615:B6M10:T:0:81=2:0;84,88:0:0:3:0:213:0
:@1091
KGUN-DT,KGUN-DT:189028615:B6M10:T:0:49=2:0;52:0:0:3:0:215:0
:@1092
MEXI   ,MEXI   :189028615:B6M10:T:0:65=2:0;68:0:0:4:0:215:0
:@
KMSB,KMSB:539028615:B6M10:T:0:49=2:0;52:0:0:3:0:217:0
:@1131
KOLD-DT,KOLD-DT:213028615:B6M10:T:0:49=2:0;52:0:0:3:0:219:0
:@1132
Weather,Weather:213028615:B6M10:T:0:65=2:0;68:0:0:4:0:219:0
:@1133
Tube,Tube:213028615:B6M10:T:0:81=2:0;84:0:0:5:0:219:0
:@1181
KTTU-DT,KTTU-DT:503028615:B6M10:T:0:17=2:0;20:0:0:1:0:221:0
:@1271
PBS HD,PBS HD:557028615:B6M10:T:0:49=2:0;52,56:0:0:1:0:223:0
:@1272
KIDS,KIDS:557028615:B6M10:T:0:65=2:0;68,72:0:0:2:0:223:0
:@1273
WORLD,WORLD:557028615:B6M10:T:0:81=2:0;84:0:0:3:0:223:0
:@1401
KHRR-40, Telemundo Tucson, 
AZ,KHRR-DT:629028615:B6M10:T:0:49=2:0;52,54:0:0:3:0:225:0
:@1461
Univision,KUVE-DT:665028615:B6M10:T:0:49=2:0;52:0:0:1:0:179:0
:@1462
TeleFutura,KFTU-CA:665028615:B6M10:T:0:65=2:0;68:0:0:2:0:179:0
:@1581
KWBA-1,KWBA-1:653028615:B6M10:T:0:49=2:0;50:0:0:3:0:207:0
:@1582
KWBA-2,KWBA-2:653028615:B6M10:T:0:65=2:0;66:0:0:4:0:207:0

Adding a channel number to that last field (13) seems to cause problems with 
vdradmin getting guide data for the channels.

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Sunday, August 23, 2009 1:26 PM
Subject: Re: [vdr] Turn off/relocate ts error logging


> On 23.08.2009 20:03, Timothy D. Lenz wrote:
> > Form /var/log/user.log:
> >
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (2)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (6)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (9)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (11)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (8)
>
> This doesn't come from VDR (any more), because it no longer uses
> cTS2PES.
>
> > But in looking at the log now with it having run a bit with good signal, I 
> > find another log spam:
> >
> > Aug 23 10:44:18 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
> > Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=eng,72=eng:0:0
> > Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
> > Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
> > Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa,72=spa:0:0
> > Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng,88=eng:0:0
> > Aug 23 10:45:21 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
> > Aug 23 10:45:42 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;50=eng:0:0
> > Aug 23 10:45:42 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;66=spa:0:0
> > Aug 23 10:46:03 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
> > Aug 23 10:46:03 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
> > Aug 23 10:46:24 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:46:24 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
> > Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=eng:0:0
> > Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
> > Aug 23 10:47:06 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 17+17=2:0;20=eng:0:0
> > Aug 23 10:47:27 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:47:48 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=en

Re: [vdr] Turn off/relocate ts error logging

[Timothy D. Lenz]

for the TS error:

[14:01]  simply comment out that line in vdr172_remux.c

../PLUGINS/src/xine-0.9.3/vdr172remux.c

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Sunday, August 23, 2009 2:15 AM
Subject: Re: [vdr] Turn off/relocate ts error logging


> On 22.08.2009 19:12, Timothy D. Lenz wrote:
> > My log files get so big it,s very hard to check them because of the ts 
> > error messages that get flooded to it. I've had logs near
2gb
> > in size. I have a problem with xine crashing when there is a weak signal 
> > and the ts loging bloating the log files is creating a
lot
> > of problems. Need a way to turn off ts error loging or relocate to another 
> > file.
>
> Are these reports coming from the core VDR or from xine?
>
> 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] Turn off/relocate ts error logging

[Timothy D. Lenz]

>From the auther of the atsc plugin:

Yes, that's from the plugin. To fix it, find the following line in VDR's 
channels.c

Code:
dsyslog("changing pids of channel %d from %d+%d=%d:%s:%s:%d to 
%d+%d=%d:%s:%s:%d", Number(), vpid, ppid, vtype, OldApidsBuf,
OldSpidsBuf, tpid, Vpid, Ppid, Vtype, NewApidsBuf, NewSpidsBuf, Tpid);

and change it to

Code:
if (Number())
  dsyslog("changing pids of channel %d from %d+%d=%d:%s:%s:%d to 
%d+%d=%d:%s:%s:%d", Number(), vpid, ppid, vtype, OldApidsBuf,
OldSpidsBuf, tpid, Vpid, Ppid, Vtype, NewApidsBuf, NewSpidsBuf, Tpid);

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Sunday, August 23, 2009 1:26 PM
Subject: Re: [vdr] Turn off/relocate ts error logging


> On 23.08.2009 20:03, Timothy D. Lenz wrote:
> > Form /var/log/user.log:
> >
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (2)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (6)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (9)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (11)
> > Aug 23 10:53:31 LLLx64-32 vdr: [2635] TS continuity error (8)
>
> This doesn't come from VDR (any more), because it no longer uses
> cTS2PES.
>
> > But in looking at the log now with it having run a bit with good signal, I 
> > find another log spam:
> >
> > Aug 23 10:44:18 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
> > Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=eng,72=eng:0:0
> > Aug 23 10:44:39 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
> > Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
> > Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa,72=spa:0:0
> > Aug 23 10:45:00 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng,88=eng:0:0
> > Aug 23 10:45:21 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
> > Aug 23 10:45:42 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;50=eng:0:0
> > Aug 23 10:45:42 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;66=spa:0:0
> > Aug 23 10:46:03 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
> > Aug 23 10:46:03 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
> > Aug 23 10:46:24 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:46:24 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa:0:0
> > Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=eng:0:0
> > Aug 23 10:46:45 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
> > Aug 23 10:47:06 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 17+17=2:0;20=eng:0:0
> > Aug 23 10:47:27 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:47:48 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng:0:0
> > Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
> > Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=eng,72=eng:0:0
> > Aug 23 10:48:09 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng:0:0
> > Aug 23 10:48:30 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=eng,56=eng:0:0
> > Aug 23 10:48:30 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 65+65=2:0;68=spa,72=spa:0:0
> > Aug 23 10:48:30 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 81+81=2:0;84=eng,88=eng:0:0
> > Aug 23 10:48:51 LLLx64-32 vdr: [2230] changing pids of channel 0 from 
> > 0+0=0:0:0:0 to 49+49=2:0;52=spa:0:0
> > Aug 23 10:49:12 LLLx64-32 vdr: [2230

[vdr] No audio with vdr-1.7.9

[Timothy D. Lenz]

I tried going from 1.7.8 to 1.7.9 and I have no audio with .9

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