Hi Patrick (and of course Klaus ;o))
> For some days there i a new "Test Feed" channel being found automatic
> new channel scanner of vdr-1.6.0:
>
> root@black:/etc/vdr# tail -1 channels.conf
> Test Feed;Test Feed:10920:hC56:S19.2E:22000:0:0:0:0:0:1:1063:0
> root@black:/etc/vdr#
I pretty much had the same problem. AFTER discovering what was
wrong, I simply deleted the "Test Feed" channel and VDR went back
to normal operation. Actually, I woke up in the middle of the night
…
[View More]because my TV set was continually blinking a white screen at me
every few minutes ;o)) (Due to the drivers being reloaded), which
is how a discovered the problem at all.
I did, however, lose a good number of timered shows. Not that this
will kill me, but personally I don't think VDR should quit operations
because of such a "simple" problem.
If there is an error in the channels.conf I see no reason to restart
VDR more than once. If the conf file is defunct, then no number
of restarts will bring it back to life ;o))
Personally, >>I<< think VDR should log such a problem and
then display it on screen (I mean that's what the message bar
is for ;o)) until the user aknowledeges that the message has
been read.
While I am at problem discussing, I also think that VDR should
NOT delete a timer, if it wasn't possible to fully record the movie.
(This can happen if diskspace runs low or if a thunderstrom
prevents good reception, e.g.) Here, too, either keep the timer
(even if the movie is over) or at least post a message in the
message bar "Timer xyz + movie title" wasn't recorded. Keep
up the display until it is aknowledged by the user.
I know I haven't been posting recently (or doing any "nessy
patches (insider for the older VDR users ;o))), but I still use
and will continue to do so, only VDR as my method of
recording and watching TV or beamer.
@Klaus: Do you think the above would be possible?
kind regards,
Reinhard
[View Less]
2008/6/18 Michael Brakemeier <michael(a)brakemeier.de>:
> Have you tried the -jw4 Version from Joachims website?
> This should fix the ?-issue - it does this at least for me, my
> display now correctly prompts "Taste drücken..." instead of
> "Taste dr?cken..." on power off.
I tried now =) I hadn't even noticed a new version before. And, it
really does fix the problem with VDR messages, so Joachim must've
changed something. But I still get ?-marks for commands from the
…
[View More]commands menu. For example, I have "Äänet pois / päälle" -command in
commands.conf. That is displayed correctly when I browse the menu. VDR
is supposed to display the name of the command after I run it, and
does, but then the Ä and ä are displayed as ?-marks.
Still, thanks go to Joachim for maintaining this plugin!
-Ville
--
Ville Aakko - ville.aakko(a)gmail.com
--
--
Ville Aakko - ville.aakko(a)gmail.com
[View Less]
---------- Forwarded message ----------
From: Ville Aakko <ville.aakko(a)gmail.com>
Date: 2008/6/17
Subject: Re: [vdr] lcdproc, utf-8 & VDR
To: Hanno Zulla <abos(a)hanno.de>
2008/6/17 Hanno Zulla <abos(a)hanno.de>:
>
> You might want to try Joachim Wilke's patched version of the lcdproc plugin.
Yes, I'm already using that. I believe helped Joachim beta test the
patch =) Although I'm not sure that the patch I got from Joachim is
exactly same as on his homepage, but …
[View More]I'd suspect so.
It's working marvelously! Although, I noticed that messages in VDR
(from external commands, or stuff like "VDR sammuu myöhemmin" transl.
"VDR is shutting down later") have ?-marks instead of the scandinavian
letters aka. umlauts. But I've been too lazy to report that back to
Joachim =)
- Ville
--
--
Ville Aakko - ville.aakko(a)gmail.com
--
--
Ville Aakko - ville.aakko(a)gmail.com
[View Less]
Hi!
My VDR with utf-8 is working marvelously, except for a small cosmetic
problem. The non-7-bit characters are not shown correctly on my LCD.
The LCD expects characters (i.e. it is no a graphics-LCD, or at least
the kernel module isn't), in a certain character set (iso-8859-15
probably but I can't be actually sure, something very similar though).
The vdr-lcdproc outputs characters in utf-8 (since I want to use
utf-8). So, a utf-8 to iso-8859-15 conversion is required in the chain
VDR-lcdproc-…
[View More]LCDd-/dev/lcd0. Currently none of the aforementioned can
do the conversion.
I can do the wollowing:
'echo ä | iconv -f utf-8 -t iso8859-15 > /dev/lcd0'
To show a real "ä" on my LCD. So, I tried the following workaround on my box:
- mkfifo fakelcd
- tail fakelcd | iconv -f utf-8 -t iso8859-15 > /dev/lcd0
- Point LCDd to fakelcd
(this is as I recall I tried it, it was some weeks ago when I did the
actual tests)
The above would work otherwise, but iconv doesn't "tail" - i.e. it
waits for EOF (or something). I could do 'cat somefile > fakelcd',
with somefile containing utf-8 characters and it was shown, but that
won't work with VDR. Any other suggestions?
Also, in your opinion, which one in the chain
VDR-lcdproc-LCDd-/dev/lcd0 should be responsible of the conversion of
the character set? I'm asking so I know which programs author should I
point my whine to =)
Cheers!
- Ville
--
--
Ville Aakko - ville.aakko(a)gmail.com
[View Less]
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: â…
[View More]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 270000
--- 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 270000
------------------------------------------------
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.
[View Less]
Hi
I'm building a new x86_64 system and can't compile xine-lib. I get this
error:
_cdio_linux.c: In function 'get_mcn_linux':
_cdio_linux.c:305: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
_cdio_linux.c:305: warning: pointer targets in passing argument 1 of
'__strdup' differ in signedness
_cdio_linux.c: In function 'eject_media_linux':
_cdio_linux.c:415: error: 'INT_MAX' undeclared (first use in this function)
_cdio_linux.c:415: error: (Each undeclared …
[View More]identifier is reported only once
_cdio_linux.c:415: error: for each function it appears in.)
_cdio_linux.c: In function '_read_mode2_sector_linux':
_cdio_linux.c:722: warning: dereferencing type-punned pointer might break
strict-aliasing rules
make[5]: *** [_cdio_linux.lo] Error 1
make[5]: Leaving directory
`/usr/src/development/xine-lib-cvs-20070829224000/src/input/vcd/libcdio'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/usr/src/development/xine-lib-cvs-20070829224000/src/input/vcd/libcdio'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/usr/src/development/xine-lib-cvs-20070829224000/src/input/vcd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/usr/src/development/xine-lib-cvs-20070829224000/src/input'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/usr/src/development/xine-lib-cvs-20070829224000/src'
make: *** [all-recursive] Error 1
[root@freddy xine-lib]# rpm -qa | grep cdio
libcdio-0.79-3.fc9.x86_64
libcdio-devel-0.79-3.fc9.x86_64
Any ideas?
[View Less]