Re: [vdr] Request: E parameter in channels.conf for epg scan
Dear Pasi,
it is a great idea to fork a new line and rewrite code to satisfy all
requests which been put forward.
Please let me know when you will set a repository and write stable code
so that I could give it a try. Please make changes quick so that people
who was waiting for this changes had a chance to have better software.
You will be our hero.
NOTE: many demand but few commit time and do it.
Thank you,
Andy
On 17/12/10 1:58 PM, Pasi Juppo wrote:
On 12/15/2010 10:49 PM, Ville Skyttä wrote:
> On Wednesday 15 December 2010,
Jouni Karvo wrote:
>>
>> I think adding dependencies to outside packages is a
burden that
>> should be avoided. There are already many things I need
to install
>> separately in order the vdr box to work; kernel, graphics
drivers,
>> and xine-lib. Luckily, lirc is now already part of the
kernel, and
>> DVB drivers, too; much less hassle than before. This is
the right
>> direction to go - not adding more moving parts that need
to be
>> installed (with compatible versions).
>
> I'm not saying anything about the epg data as plain text vs
sqlite
> thing, but would like to note that things are not always that
black
> and white as the above seems to say. In my opinion it does
not make
> sense to reimplement everything that's required just in order
to
> avoid dependencies (but other valid reasons for not using
something
> that's already there might of course exist).
And it's not only to avoid unnecessary wheel inventing but also going
towards more generic solution of the software itself. If I'm not
mistaking sqlite would actually help also in multi-instance ("server"
solution) vdr implementation when each instance would be
reading/writing from/to same DB but also external tools to read/write
epg data way more faster than via vdr.
But this depate can go on forever back and forth - probably leading to
no changes what so ever. Klaus have already decided few posts ago to
keep the text file based solution. Same goes for standalone-server
wishes (vdr will not change to server-client system). And same for few
other features.
That said and with no disrespect to the author of vdr in my opinion it
starts to be a time to fork vdr and redefine its base + few other
elements. There are many very talented coders reading this
mailing-list (+ many others over different vdr related sites) who are
developing plugins and patches - some being very big. Put sources to
accessible version control system (almost already existing at place
where previously unmaintained plugins where brought alive), set up
issue handling system with roadmaps etc. (like Mantis) and of course
set up a core team of developers who make decisions what go in and
what not. I believe this would also speed up the development of the
vdr itself tremendeously due to much greater man power.
Of course things can remain the same but will we ever see natively
implemented in vdr:
-_proper_ implementation of server-client solution (centralized
records, epg etc. without "hacks")
-good looking high res OSD
-good integration to XBMC or similar
-fully redefinable menu system
-channel specific configurability (epg...)
-native ATSC support
-several of the big patches integrated (long list) and configurable
-etc.etc.
If I've not read incorrectly what have been written in this
mailing-list then the answer is *no*.
Hope to get some active discussion around this and actions as well.
Br, Pasi
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12/15/2010 10:49 PM, Ville Skyttä wrote:
On Wednesday 15 December 2010, Jouni Karvo wrote:
>
> I think adding dependencies to outside packages is a burden that
> should be avoided. There are already many things I need to install
> separately in order the vdr box to work; kernel, graphics drivers,
> and xine-lib. Luckily, lirc is now already part of the kernel, and
> DVB drivers, too; much less hassle than before. This is the right
> direction to go - not adding more moving parts that need to be
> installed (with compatible versions).
I'm not saying anything about the epg data as plain text vs sqlite
thing, but would like to note that things are not always that black
and white as the above seems to say. In my opinion it does not make
sense to reimplement everything that's required just in order to
avoid dependencies (but other valid reasons for not using something
that's already there might of course exist).
And it's not only to avoid unnecessary wheel inventing but also going
towards more generic solution of the software itself. If I'm not
mistaking sqlite would actually help also in multi-instance ("server"
solution) vdr implementation when each instance would be reading/writing
from/to same DB but also external tools to read/write epg data way more
faster than via vdr.
But this depate can go on forever back and forth - probably leading to
no changes what so ever. Klaus have already decided few posts ago to
keep the text file based solution. Same goes for standalone-server
wishes (vdr will not change to server-client system). And same for few
other features.
That said and with no disrespect to the author of vdr in my opinion it
starts to be a time to fork vdr and redefine its base + few other
elements. There are many very talented coders reading this mailing-list
(+ many others over different vdr related sites) who are developing
plugins and patches - some being very big. Put sources to accessible
version control system (almost already existing at place where
previously unmaintained plugins where brought alive), set up issue
handling system with roadmaps etc. (like Mantis) and of course set up a
core team of developers who make decisions what go in and what not. I
believe this would also speed up the development of the vdr itself
tremendeously due to much greater man power.
Of course things can remain the same but will we ever see natively
implemented in vdr:
-_proper_ implementation of server-client solution (centralized records,
epg etc. without "hacks")
-good looking high res OSD
-good integration to XBMC or similar
-fully redefinable menu system
-channel specific configurability (epg...)
-native ATSC support
-several of the big patches integrated (long list) and configurable
-etc.etc.
If I've not read incorrectly what have been written in this mailing-list
then the answer is *no*.
Hope to get some active discussion around this and actions as well.
Br, Pasi
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
Ok, i found that i get the debugging from running vdr and piping it output to a file. I removed the log serial numbers hopefully. I can't see anything wrong though, i changed from fta, to encrypted channels and back, also went through the cam menu while on the encrpyted channels. Do I need to do anything with channels.conf to let it know i have encrypted channels? I just piped the output from dvbscan to channels.conf ... oliver On 12/17/10 00:36, Oliver Schinagl wrote: > I think it's working I got this from my cam in my message: > > > Dec 17 00:24:01 erin vdr: [14866] CAM 1: Menu -- > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Conax Conditional Access' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Main menu' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Subscription status' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Event status' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Tokens status' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Change CA PIN' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Maturity Rating' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Modem Ordering' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'About Conax CA' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Message' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Language' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Loader status' > Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press > 'EXIT' to return' > Dec 17 00:24:02 erin vdr: [14866] max. latency time 3 seconds > Dec 17 00:24:03 erin vdr: [14866] CAM 1: select 0 > Dec 17 00:24:03 erin vdr: [14866] CAM 1: Menu -- > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Conax Conditional Access' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Subscription status' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Name: Digitenne ' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Start date 01. Dec 2010 01. > Jan 1990' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'End date 31. Dec 2010 01. > Jan 1990' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Entitlement 010b 01ff' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'The First Entitlement' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'The End Entitlement' > Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'OK - view subscription status' > Dec 17 00:24:39 erin vdr: [15132] ERROR: no useful data seen within > 10540220 byte of video stream > Dec 17 00:27:48 erin vdr: [15132] PES packet shortened to 27080 bytes > (expected: 53845 bytes) > Dec 17 00:30:32 erin vdr: [14866] CAM 1: select 4 > Dec 17 00:30:33 erin vdr: [14866] CAM 1: Menu -- > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Conax Conditional Access' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Subscription status' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Name: Digitenne ' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Start date 01. Dec 2010 01. > Jan 1990' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'End date 31. Dec 2010 01. > Jan 1990' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Entitlement 010b 01ff' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'The First Entitlement' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'The End Entitlement' > Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'OK - view subscription status' > Dec 17 00:30:33 erin vdr: [14866] [xine..put] OSD bandwidth: 1077562 > bytes/s (8418 kbit/s) > Dec 17 00:30:34 erin vdr: [14866] CAM 1: Menu -- > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Conax Conditional Access' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Main menu' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Subscription status' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Event status' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Tokens status' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Change CA PIN' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Maturity Rating' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Modem Ordering' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'About Conax CA' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Message' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Language' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Loader status' > Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press > 'EXIT' to return' > Dec 17 00:30:35 erin vdr: [14866] [xine..put] OSD bandwidth: 918770 > bytes/s (7177 kbit/s) > Dec 17 00:30:35 erin vdr: [14866] CAM 1: select 1 > Dec 17 00:30:36 erin vdr: [14866] CAM 1: Menu -- > Dec 17 00:30:36 erin vdr: [14866] CAM 1: '' > Dec 17 00:30:36 erin vdr: [14866] CAM 1: 'No Entitlement!' > Dec 17 00:30:36 erin vdr: [14866] [xine..put] OSD bandwidth: 857737 > bytes/s (6701 kbit/s) > Dec 17 00:30:37 erin vdr: [14866] CAM 1: Menu -- > Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Conax Conditional Access' > Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Main menu' > Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Subscription status' > Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Event status' > Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Tokens stat
