[vdr] Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Hi! I've had problems with two episodes of a documentary series about drugs and the human brain running on Finnish YLE Teema (originally a French documentary by ARTE France NOVAPROD OWL). The audio channels are labeled wrongly in the recordings (there is the original French commentary / dubbed interviews and one with Finnish commentary / original interviews), but more importantly, subtitles are not replayed in the recordings! I've had no problems with DVB subtitles on other recordings I've made. Wathing the program in real-time has no problems, there I can see the subtitles without problems. Only the recordings have problems. Is this problem only on my setup? I haven't checked into this in more detail yet, but those who are interested (btw. the series is really interesting) and also live in Finland, please check if you can record this correctly. There is a rerun today of the 3rd episode: YLE Teema: 18.00 Huumetta aivoille And, since this is a 5-episode series, there'll be opportunities (2x2) to debug this one. The series runs on thursdays (21.00 EEST), and re-runs on saturdays (18.00 EEST). I'm watching in the Oulu region via DVB-C (OPOY/3KTV). I'm using Gentoo, and vdr 1.4.6, with bigpatch, and subtitles 0.4.0. The newest vdr is not in Gentoo yet (we -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] subtitles-0.5.0 and gentoo
can also update to developer version vdr-1.5.x > > emerge layman > > layman -a vdr-1.5 > > but dont slay us with bugs, this is the developer version ! > > We work on this 24/7 ;) > > > -- > Regards > Gentoo Developer > Joerg Bornkessel <[EMAIL PROTECTED]> > > > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] subtitles plugin: cannot record subtitles
2007/8/22, Davide <[EMAIL PROTECTED]>: > Hello everybody > I have a strange problem with the dvb subtitles plugin. On the BBC Prime > channel > BBC Prime;Globecast > UK:6:vC34:S13.0E:27500:6001:6011:6041:500:14601:318:13000:0 > the subtitles work fine during live tv, but I'm unable to see them while > replaying recordings from that channel. If I try to demux it with > projectx it looks like the subtitles are missing from the recording. Hi, I also had exactly the same problem with recording DVB subtitles, but in the stable branch VDR (1.4.x) and vdr-subtitles 0.4, under Gentoo. I told about my problems here in May, but the thread went so technical I couldn't understand what they was saying anymore =) I think Rolf Ahrenberg said he uploaded some patches somewhere, IIRC, but I don't know where. The most interesting part is that I had had no problems with subtitles in VDR ever before this summer. And it seems for some there never has been any problems. And it is still unclear what causes them (a change in VDR, a bug, or maybe in the plugin? Or a change in the YLE broadcasts in Finland?). I solved my problems by upgrading to the development version (1.5.x), since I couldn't get the subtitles working in 1.4.x back then - and this was the only reason I upgraded. I haven't had any problems since, but you already are on 1.5.x, so I don't think this helps you much. Except that now you know you're not the only one with problems with recording subtitles. Currently I'm using vdr 1.5.5-r1 and vdr-subtitles 0.5.0 (on Gentoo). > Here are the relevant setting for the plugin from setup.conf I don't think this is a config issue, since I reverted back to the default config back in May, and it had no effect on my box. I'd suggest you also try that. > subtitles.BackgroundTransparency = 0 > subtitles.Delay = 0 > subtitles.Dxr3comp = 0 > subtitles.Enabled = 1 > subtitles.ForegroundTransparency = 0 > subtitles.HearingImpaired = 0 > subtitles.Language = 0 > subtitles.Language2 = 3 > subtitles.Mainmenu = 0 > subtitles.Offset = 0 > subtitles.Record = 1 > subtitles.Sync = 1 > subtitles.VideoFormat = 0 > I'm using vdr 1.5.6-1devel1 and subtitles 0.5.0-5 from e-tobi.net. > > Any ideas? Thanks in advance. > > Regards, > Davide > > > _______ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5.10, dxr3 and subtitles
Hi! Anybody using vdr-1.5.10, dxr3 and subtitles? I'm (trying to) use it, but all subtitles have the lines caused by "too many colors in a region". I can't find the dxr3-compatibility option that used to be there in the plugin. I have disabled antialiasing in vdr's OSD settings. Anybody got dxr3 working with subtitles properly in this version? Perhaps there's a patch somewhere I haven't found? Or the setup option is hidden somewhere I couldn't find it? Or, maybe it hasn't been implemented yet in vdr-1.5.10 at all? Just wondering, - Ville -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.10, dxr3 and subtitles
2007/11/3, Klaus Schmidinger <[EMAIL PROTECTED]>:
> VDR reduces the colors if the output device can't display all of them.
>
> Maybe the dxr3 device doesn't correctly respond to the CanHandleAreas()
> call?
>
> See cDvbSubtitleConverter::FinishPage(), the calls to sr->ReduceBpp()
> and sr->ShrinkBpp().
Yes, I think you are probably right. I looked at the code and modified
it so that bpp ís always reduced to 2 (I think) - hack included. I'm
not a programmer and know nothing about C++, really. But it works for
me (kind of - see below). Of course, this is not a proper fix.
But, I think from previous the discussion here, that the color depth
dxr3 can handle isn't that straightforward for. It can handle 8bpp but
in a limited way; so just reducing bpp would not use the dxr3 hardware
to the full potential. Some additional checking and processing is
needed? Though I'm just an end user really, I don't know really, I'm
kind of guessing =). Anyways, the subtitles look really good even with
2bpp, so in this case I think just reducing is sufficient.
There's still problem even after reducing the bpp; I think the OSD
levels isn't properly implemented in the CVS (dxr3-0-2 branch). I'll
post about this in the dxr3plugin-users list. (Symptoms: No other OSD
is shown while subtitles are shown, previous subtitles aren't
"cleared").
- Ville
--
Ville Aakko - [EMAIL PROTECTED]
diff -Naur vdr-1.5.10/dvbsubtitle.c vdr-1.5.10.old/dvbsubtitle.c
--- vdr-1.5.10/dvbsubtitle.c 2007-11-04 13:01:35.0 +0200
+++ vdr-1.5.10.old/dvbsubtitle.c 2007-11-04 12:59:42.0 +0200
@@ -984,10 +984,10 @@
int NumAreas = Page->regions.Count();
int Bpp = 8;
bool Reduced = false;
-// while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) {
+ while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) {
int HalfBpp = Bpp / 2;
if (HalfBpp >= 2) {
- while (int i = 0; i < NumAreas; i++) {
+ for (int i = 0; i < NumAreas; i++) {
if (Areas[i].bpp >= Bpp) {
Areas[i].bpp = HalfBpp;
Reduced = true;
@@ -997,7 +997,7 @@
}
else
return; // unable to draw bitmaps
-//}
+}
if (Reduced) {
for (int i = 0; i < NumAreas; i++) {
cSubtitleRegion *sr = Page->regions.Get(i);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.10, dxr3 and subtitles
Oops,
wrong patch!
Right hacky thingy attached.
--
Ville Aakko - [EMAIL PROTECTED]
diff -Naur vdr-1.5.10/dvbsubtitle.c vdr-1.5.10-new/dvbsubtitle.c
--- vdr-1.5.10/dvbsubtitle.c 2007-10-14 17:02:35.0 +0300
+++ vdr-1.5.10-new/dvbsubtitle.c 2007-11-04 13:17:19.0 +0200
@@ -982,13 +982,13 @@
return;
tArea *Areas = Page->GetAreas();
int NumAreas = Page->regions.Count();
- int Bpp = 8;
+ int Bpp = 4;
bool Reduced = false;
- while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) {
+// while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) {
int HalfBpp = Bpp / 2;
if (HalfBpp >= 2) {
for (int i = 0; i < NumAreas; i++) {
- if (Areas[i].bpp >= Bpp) {
+ while (Areas[i].bpp >= Bpp) {
Areas[i].bpp = HalfBpp;
Reduced = true;
}
@@ -997,7 +997,7 @@
}
else
return; // unable to draw bitmaps
-}
+//}
if (Reduced) {
for (int i = 0; i < NumAreas; i++) {
cSubtitleRegion *sr = Page->regions.Get(i);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 and 1.5.11 antialiasing
Hi Jan, Just in case "vdr: [3936] ERROR: FreeType: error during FT_Render_Glyph 32, 3" is not caused by this / VDR does not crash because of that (I'm not getting that error), I've noticed that VDR does not start at all if I enable text2skin. It used to work in vdr-1.5.10 but not in 1.5.11 anymore, VDR just dies if I enable it. In the logs I get this: Nov 18 20:01:35 VillenVDRdevil kernel: em8300_video.o: Video sync rdptr is stuck at 0xdc01, wrptr 0xdcfb, left 250 Nov 18 20:01:35 VillenVDRdevil kernel: em8300_video.o: Video sync timeout And then VDR dies. If I disable it and use skinsoppalusikka instead, everything is OK. It even seems more stable (i.e. as stable as text2skin) than it used to, though I haven't done extensive testing yet. I'm on Gentoo, though. I'm having strange problems there with my dxr3 and >VDR-1.5.10 that other people on other distros don't. This could be one of those. - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.5.10 and VDR-1.5.11 recording channel with subtitle
Hi! 2007/11/5, Dave P <[EMAIL PROTECTED]>: > On Sunday 04 Nov 2007, NIVAL Michaël wrote: > > Hi, > > > > When I record channel with subtitle, VDR brutally restart. > > > > Here is the content of the syslog, just before restarting : I'm having exactly the same problem! VDR does an emergency exit every 2-10 minutes when recording a program with subtitles (currently, a documentary about atomic weapons on YLE 2). I'm on VDR-1.5.11 currently, have one DVB-C (budget) card and a dxr3 card. I haven't noticed this before, and I'm not sure actually if this is the same problem, since I haven't used TV a lot recently because of being busy... but I quicly checked recent recordings, and all of them are ruined because of this constant restarting (well, perhaps not ruined but nevertheless have ugly gaps / missing a few seconds every few minutes). I don't know if I've done any recordings without subtitles recently, but I'll check if they're OK when I have the time. In my syslog, I got exactly similar entries as Michael, like so: Nov 21 00:15:33 VillenVDRdevil vdr: [6900] buffer usage: 70% (tid=6899) Nov 21 00:15:33 VillenVDRdevil vdr: [6900] buffer usage: 80% (tid=6899) Nov 21 00:15:35 VillenVDRdevil vdr: [6900] buffer usage: 90% (tid=6899) Nov 21 00:15:35 VillenVDRdevil vdr: [6899] clearing transfer buffer to avoid overflows Nov 21 00:15:35 VillenVDRdevil vdr: [6900] buffer usage: 0% (tid=6899) Nov 21 00:15:35 VillenVDRdevil vdr: [6899] dxr3: audiodecoder: sample rate=48000 Nov 21 00:15:35 VillenVDRdevil vdr: [6899] dxr3: audiodecoder: channels=2 Nov 21 00:15:37 VillenVDRdevil vdr: [6899] dxr3: audiodecoder: sample rate=48000 Nov 21 00:15:37 VillenVDRdevil vdr: [6899] dxr3: audiodecoder: channels=2 Nov 21 00:15:39 VillenVDRdevil vdr: [6900] buffer usage: 70% (tid=6906) Nov 21 00:15:40 VillenVDRdevil vdr: [6900] buffer usage: 80% (tid=6906) Nov 21 00:15:41 VillenVDRdevil vdr: [6907] dxr3: cSPUEncoder::Flush: OSD data size: 8288 Nov 21 00:15:42 VillenVDRdevil vdr: [6900] buffer usage: 90% (tid=6906) Nov 21 00:15:43 VillenVDRdevil vdr: [6900] buffer usage: 100% (tid=6906) Nov 21 00:15:43 VillenVDRdevil vdr: [6900] ERROR: 1 ring buffer overflow (65 bytes dropped) Nov 21 00:15:44 VillenVDRdevil vdr: [6907] dxr3: cSPUEncoder::Flush: OSD data size: 8623 Nov 21 00:15:49 VillenVDRdevil vdr: [6900] ERROR: 10186 ring buffer overflows (1914968 bytes dropped) Nov 21 00:15:49 VillenVDRdevil vdr: [6907] dxr3: cSPUEncoder::Flush: OSD data size: 4947 Nov 21 00:15:52 VillenVDRdevil vdr: [6907] dxr3: cSPUEncoder::Flush: OSD data size: 7312 Nov 21 00:15:55 VillenVDRdevil vdr: [6900] ERROR: 13027 ring buffer overflows (2449076 bytes dropped) Nov 21 00:15:56 VillenVDRdevil vdr: [6907] dxr3: cSPUEncoder::Flush: OSD data size: 7863 Nov 21 00:15:59 VillenVDRdevil vdr: [6905] ERROR: video data stream broken Nov 21 00:15:59 VillenVDRdevil vdr: [6905] initiating emergency exit Nov 21 00:15:59 VillenVDRdevil vdr: [6835] emergency exit requested - shutting down I believe only the last three lines are significant. Is there a workaround for this? I remember seeing someone with a patch that prevented this (IMHO idiotic) emergency exits, but OTOH the patches could have been for a different issue. -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.5.10 and VDR-1.5.11 recording channel with subtitle
2007/11/21, Klaus Schmidinger <[EMAIL PROTECTED]>: > They have saved quite a few recordings for me. > But since they are so "idiotic" (which, I guess, makes me the idiot, > since I've implemented them), I'll make them configurable soon. Oh, sorry, I didn't mean it personally (really!). I was just a bit mad at the time of writing. The automatic restarts might be good for some situations (like bad drivers) but definately not for others, like this. And, if there is something wrong, _primarily_ one should seek out why and what is wrong, not start restarting applications... but as you stated for some situations that might be a workaround for some situations (albeit temporary until there's a real fix for the cause). Overall, VDR is a very nice project! And, one must remember that 1.5.x is the development branch (IIRC). Anyways, I think there's something else going on, too. I checked my syslogs, and I haven't had this problem before 18.11.2007 (my syslogs range back some weeks-months, and I do recordings of certain programmes with and without subtitles weekly). On 18.11. I upgraded to 1.5.11 from 1.5.10, and afterwards, ALL recordings with subtitles have had these restarts. I get no such problems if I'm recording a channel without subtitles or just watch a program with subtitles (or without). But, I need to verify this. I've had too few regordings after 18.11. (maybe 2-4), it could have been just bad transmissions (weirdly coincidentally, if they were just now and on several channels). Though, I'm quite busy on these few days / weeks but I'll get back when I've done some more investigations and testings what is going on. In the meantime, just wanted to drop a note here, in case someone is hit by a similar problem =). And, Klaus, keep up the work with VDR! - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 and 1.5.11 antialiasing
2007/11/18, Ville Aakko <[EMAIL PROTECTED]>: > And then VDR dies. If I disable it and use skinsoppalusikka instead, > everything is OK. It even seems more stable (i.e. as stable as > text2skin) than it used to, though I haven't done extensive testing > yet. I have to correct this: skinsoppalusikka is still unstable on dxr3 (as it always used to be for me and at least some others). You get the occasional freezes and garbled OSD, if you use the menus (as you get with any other skin, except than those made via text2skin). So there is no stable skin for dxr3 users on vdr-1.5.11 currently. - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.5.10 and VDR-1.5.11 recording channel with subtitle
2007/11/21, Reinhard Nissl <[EMAIL PROTECTED]>: > Ville Aakko schrieb: > > > On 18.11. I upgraded to > > 1.5.11 from 1.5.10, and afterwards, ALL recordings with subtitles have > > had these restarts. I get no such problems if I'm recording a channel > > without subtitles or just watch a program with subtitles (or without). > > Release 1.5.11 fixed one subtitling issue and caused the issue you are > seeing. In 1.5.12, the offending change has been reverted and the > subtitling issue has been fixed by a different approach. I'm going to downgrade to 1.5.10 since it used to work for me (1.5.12 isn't in the Gentoo vdr-1.5 overlay I'm using currently, so upgrading is not an option). Though, I did some investigations into this on my own. AFAICT, the subtitle changes that were also discussed here were added to the ebuild 1.5.11-r1 on the overlay on 11.11. (vdr-1.5.11-ringbuffer-remux.diff). Are other patches besides vdr-1.5.11-ringbuffer-remux.diff needed? I tried adding vdr-1.5.11-subtitle_fixes.diff but it didn't fix this, I still get the emergency exits (or, if I uncomment that feature, then all recordings end prematurely, and I believe that the picture jerks in live views but there hasn't been anything interesting enough to capture my attention for the required 5-10 minutes during testing to verify that). OTOH I don't see anyone mentioning anything about emergency exits in the "vdr-1.5.11 & subtitling problems". Maybe what I encountered was a different problem, after all? - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 and 1.5.11 antialiasing
(please don't top post) 2007/11/23, Theunis Potgieter <[EMAIL PROTECTED]>: > Is this related to `xine -V xxmc` too? The skin skinsoppalusikka's colours > appears wrong when I use the video driver xxmc in vdr-xine. It also appears > to do a "clearscreen" everytime the OSD updates, which is annoying if you > have the playback bar updating every second. I haven't used xine, so I really don't know. Maybe I should test it with dxr3... But, I also notice that skinsoppalusikka displays wrong colors in the display logos, if you constantly change channels - if you wait until the OSD clears (i.e. the channel info is not displayed anymore), then the logo is displayed correctly when you change a channel. It seems as if the palette isn't updated if you don't let the OSD clear itself. Is this what you meant? Otherwise the OSD's colors are correct. Occasionally the OSD freezes (i.e. it is unresponsive for a while), or, more commonly, becomes garbled, i.e. as if the OSD was out of sync for a second or a few more. These are the dxr3-specific problems I was referring. DXR3 users get them with ANY OTHER SKIN than text2skin (and enElchi), even the default ones (console and st_tng) - they are NOT soppalusikka specific. I haven't noticed any problems with the refreshing OSD on dxr3 (i.e. everything is displayed correctly), but if that really is happening, it could explain why skinsoppalusikka occasionally hangs and becomes garbled on dxr3. - Ville p.s. I also noticed that text2skin being unusable in 1.5.11 is caused by some skins (not enElchi) that used to work before, crashing the whole thing when the files are loaded by text2skin. By removing them I got the text2skin working again. Maybe I should post a message here about 1.5.1x and dxr3 at some point, with all the patches I've gathered... -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.12 & text2skin: how to compile?
Hi, 2008/1/1, Andrey Kuzmin <[EMAIL PROTECTED]>: > > getting build error: > > make[1]: Entering directory `/ego/vdr/33/vdr-1.5.12/PLUGINS/src/text2skin' > g++ -Wall -Woverloaded-virtual -O2 -g -c -DHAVE_IMAGEMAGICK -DHAVE_FREETYPE > -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"text2skin"' -I/usr/include/freetype2 > -I../../../include -I../../../../DVB/linux/include -I../../../../DVB/include > -I. -o text2skin.o text2skin.c > text2skin.c: In member function 'virtual bool cText2SkinPlugin::Start()': > text2skin.c:28: ошибка: некорректное преобразование из 'char*' в 'int' > text2skin.c:28: ошибка: при инициализации 1 -го аргумента 'void > cText2SkinStatus::SetLanguage(int)' > make[1]: *** [text2skin.o] Ошибка 1 > make[1]: Leaving directory `/ego/vdr/33/vdr-1.5.12/PLUGINS/src/text2skin' > > *** failed plugins: text2skin I don't know why it fails (I'm using VDR 1.5.12 with text2skin currently, on Gentoo, so it is possible to compile it). but to get the errors in English build by typing 'LANG=C make' (i.e. change the LANG variable during compile). That way you'll may get more answers, I don't know how many of the programmer guys here now Russian =) Hope you get it to compile, - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.5.15 and epgsearch-0.9.23
Hi! Anybody got vdr-epgsearch working with vdr 1.5.15? In Gentoo (via vdr-1.5 overlay ebuilds?). The emerge fails here, complete log attached (sorry for the color codes). The relevant errors are, I belive (sorry if the line breaks are messed up, the attached log should be OK): mail.c:365: error: ambiguous overload for 'operator<<' in 'std::operator<< [with _Traits = std::char_traits](((std::basic_ostream >&)((std::basic_ostream >*)newMailConflicts.std::basic_ostringstream, std::allocator >::.std::basic_ostream<_CharT, _Traits>::operator<< [with _CharT = char, _Traits = std::char_traits](((cConflictCheckTimerObj*)it. std::_Rb_tree_const_iterator<_Tp>::operator* [with _Tp = cConflictCheckTimerObj*]())->cConflictCheckTimerObj::Event()->cEvent::EventID(, ((const char*)"|")) << tChannelID::ToString() const()' Copies for the author. If you have any patches to test I'll be happy to help =) (copies already sent but I put the wrong mailing list address to the first email) -- -- Ville Aakko - [EMAIL PROTECTED] >>> [1m[37mcfg-update-1.8.2-r1[0m[0m: Skipping checksum index updating... [32;01m*[0m Building vdr-epgsearch-0.9.23 against vdr-1.5.15 [32;01m*[0m APIVERSION: 1.5.15 >>> Unpacking source... >>> Unpacking vdr-epgsearch-0.9.23.tgz to /var/tmp/portage/media-plugins/vdr-epgsearch-0.9.23/work [32;01m*[0m Patching Makefile [32;01m*[0m Setting Pathes ... [A[72C [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Converting to APIVERSION ... [A[72C [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Correcting Compile-Flags ... [A[72C [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Disabling file stripping ... [A[72C [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Fixing include of libsi-headers >>> Source unpacked. >>> Compiling source in /var/tmp/portage/media-plugins/vdr-epgsearch-0.9.23/work/epgsearch-0.9.23 ... g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ afuzzy.c g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ blacklist.c g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ changrp.c g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ conflictcheck.c g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ conflictcheck_thread.c g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ distance.c g++ -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_DVBPLAYER -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_TTXTSUBS -DUSE_VOLCTRL -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include -I/usr/include/ epgsearch.c g++ -
Re: [vdr] vdr 1.5.15 and epgsearch-0.9.23
Hi Ludwig and Christian, I noticed the betas right after I posted the previous email, and made a local ebuild for the latest beta (0.9.24.beta19), and it emerges and runs. Hope the beta doesn't blow up my VDR =) -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.5.15 on Gentoo: random and silent crash at startup
Hi! Since VDR 1.5.10 (or thereabouts) VDR has had this weird problem - and now that the 1.6 RC is near, I decided to report it (also I've been a bit busy so I wouldn't had had the time to look into this before myself). VDR dies at startup randomly, at around 5 seconds after the startup (the Gentoo init script detects this fail, and so watchdog is newer started). Just as randomly (~50% of the times) it start without errors and is stable (as rock) in my working environment =). When it crashes, I can sometimes see the "Welcome to VDR" in my VFD, sometimes even on the output of my DXR3 (if not always but I don't have my TV turned on always), but right at that point the gentoo-vdr-scripts decide they have waited enough. This could be a gentoo-vdr-scripts bug, too. btw., this is what I run in my root crontab to work around this: START VDRpurkkakoira.sh #!/bin/bash while true ; do /etc/init.d/vdr start if [ $? -gt 0 ] ; then ### punch the VDR sleep 5s else sleep 30m fi done END This also works as an additional layer of a watchdog; hence the script name =) Usually it needs 1-5 punches (but sometimes none). I believe some plugin is to blame. At VDR upgrade (when no plugin is loaded as they usually need a recompile) VDR has never died this way. I have my suspicions but I'm not going to tell them before I do some more testing, to not to upset developers for nothing =) Here are my plugins: dxr3 femon osdteletext mplayer undelete streamdev-server lcdproc control externalplayer epgsearchonly text2skin epgsearch quickepgsearch burn So, I'm going to do some testing by disabling plugins, but in the meantime, has anyone run into the same problem? Or does anyone have any suggestions I should try? Also, I'll provide the syslog of my VDR in case someone is interested - though it didn't provide anything to me that would tell why it fails (and why it doesn't, when it doesn't). - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
Hi Luca!
2008/3/6, Luca Olivetti <[EMAIL PROTECTED]>:
> En/na Luca Olivetti ha escrit:
>
>
> >> ... and this went away when I changed the cDxr3SubpictureOsd constructor
> >> to call the cOsd with proper level. Unless I'm missing something - and I
> >> bet I am - the system seems to be working smoothly now.
> >
> > Mmh, it should be already doing it, look at line 39
> >
> >
> http://dxr3plugin.cvs.sourceforge.net/dxr3plugin/dxr3/dxr3osd_subpicture.c?revision=1.1.2.18&view=markup&pathrev=vdr-dxr3-0-2
>
>
> (slaps on head), ok, that's calling it with 0, in my local copy I'm
> calling it with Level (probably the problem was introduced when I made
> the patch for the cvs version supporting older vdr releases).
> Sorry for all the trouble.
>
> Ville, are you listening? ;-)
If you meant me then yes I am =) I made the change locally here too
and now it works correctly! Has been bugging me a long time but I've
lived with it ;)
Sami, I believe you already have it almost in order. I've been using
the development VDR all the time, and the only problem has been that
the OSD hijacked the OSD (and is now gone thanks to the osdlevel
patch). Though, if you get the problem that the OSD doesn't clear
between subtitles, then see the 2. patch I'm attaching for vdr-dxr3
plugin (though it could be in the CVS now, I'm using a tarball of the
CVS that is somewhat aged now).
For reference I'm attaching here all the patches I need to apply to
VDR (1.5.15 but probably works with older ones too) and dxr3-vdr
plugin on my setup to get it working properly. Are the Gentoo overlay
guys listening? These could go into the overlay (but the VDR patch
should of course only activate if the dxr3 use flag is set).
- Ville
--
Ville Aakko - [EMAIL PROTECTED]
diff -Naur vdr-1.5.10/dvbsubtitle.c vdr-1.5.10-new/dvbsubtitle.c
--- vdr-1.5.10/dvbsubtitle.c2007-10-14 17:02:35.0 +0300
+++ vdr-1.5.10-new/dvbsubtitle.c2007-11-04 13:17:19.0 +0200
@@ -982,13 +982,13 @@
return;
tArea *Areas = Page->GetAreas();
int NumAreas = Page->regions.Count();
- int Bpp = 8;
+ int Bpp = 4;
bool Reduced = false;
- while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) {
+// while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) {
int HalfBpp = Bpp / 2;
if (HalfBpp >= 2) {
for (int i = 0; i < NumAreas; i++) {
- if (Areas[i].bpp >= Bpp) {
+ while (Areas[i].bpp >= Bpp) {
Areas[i].bpp = HalfBpp;
Reduced = true;
}
@@ -997,7 +997,7 @@
}
else
return; // unable to draw bitmaps
-}
+//}
if (Reduced) {
for (int i = 0; i < NumAreas; i++) {
cSubtitleRegion *sr = Page->regions.Get(i);
--- dxr3osd_subpicture.c.old2008-03-06 19:30:14.0 +0200
+++ dxr3osd_subpicture.c2008-03-06 19:30:23.0 +0200
@@ -37,7 +37,7 @@
cDxr3SubpictureOsd::cDxr3SubpictureOsd(int Left, int Top) : cOsd(Left, Top)
#else
cDxr3SubpictureOsd::cDxr3SubpictureOsd(int Left, int Top, uint Level)
-: cOsd(Left, Top, 0)
+: cOsd(Left, Top, Level)
#endif
{
shown = false;
diff --unified -r1.1.2.17 dxr3osd_subpicture.c
--- dxr3osd_subpicture.c3 Sep 2007 20:24:51 - 1.1.2.17
+++ dxr3osd_subpicture.c23 Nov 2007 00:01:08 -
@@ -117,6 +117,15 @@
return Result;
}
+eOsdError cDxr3SubpictureOsd::SetAreas(const tArea *Areas, int NumAreas)
+{
+ if (shown) {
+ Spu->Clear();
+ shown = false;
+ }
+ return cOsd::SetAreas(Areas, NumAreas);
+}
+
// ==
void cDxr3SubpictureOsd::Flush()
{
diff --unified -r1.1.2.15 dxr3osd_subpicture.h
--- dxr3osd_subpicture.h3 Sep 2007 20:24:51 - 1.1.2.15
+++ dxr3osd_subpicture.h23 Nov 2007 00:01:08 -
@@ -26,7 +26,7 @@
~cDxr3SubpictureOsd();
eOsdError CanHandleAreas(const tArea *Areas, int NumAreas);
-
+eOsdError SetAreas(const tArea *Areas, int NumAreas);
void Flush();
};
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
2008/3/9, Sami Sundell <[EMAIL PROTECTED]>: > > I'm having some stability problems, though - every once in a while > changing the channel or doing some fast moves with OSD freezes the > screen. Don't know what the problem is, yet. Possibly related to this is > that the subtitles have gone missing a couple of times. I haven't been > able to pinpoint what exactly happens here, but my guess is it's got > something to do with DXR3 :P What skin are you using? I've noticed that the only skins that are usable (i.e. stable enough to use them) are those of text2skin plugin - more specifically, I use enElchi. Some other were stable, too. Anything else (including skinsoppalusikka, which is identical in appearance to enElchi but standalone) and I just can't use my VDR without losing my nerves. I still get OSD freezes, but only very rarely (i.e. maybe once in every 12 hours of active use; i.e. watching recordings and such). - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Missing EPG entry @ MTV3 now!
Hello VDR users, Is there a bug in VDR or is there a fault in the EPG data sent by MTV3? There is no Abyss in the EPG on my VDR box, even though it most certainly should be there, 22..25-01.05 EET (sat-sun). Is this a DST bug? I haven't noticed any errors on other channels. I'm using VDR 1.6.0 on Gentoo. -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Missing EPG entry @ MTV3 now!
2008/3/29, JJussi <[EMAIL PROTECTED]>: > On Saturday, 29. Marchta 2008 21:50:26 Ville Aakko wrote: > > Hello VDR users, > > > > Is there a bug in VDR or is there a fault in the EPG data sent by > > MTV3? There is no Abyss in the EPG on my VDR box, even though it most > > certainly should be there, 22..25-01.05 EET (sat-sun). Is this a DST > > bug? I haven't noticed any errors on other channels. > > > > I'm using VDR 1.6.0 on Gentoo. > > > I can see that.. In HTV cable.. > It's not just MTV3. Problems also on Nelonen and Subtv (I'm comparing to telkku.com, and quickly checked teletext in MTV3's case). Exactly one program entry is missing on each channel (Abyss on MTV3, Movie at 00.45 on Nelonen and an episode of X-Files on SubTV). Also, all programs in the night after 00:00 are moved 1 hour backwards in the EPG. It seems that someone / something (either the broadcasters or VDR) is modifying the EPG data so that the programs seem to start 1 hour earlier, so that if someone sets a timer, their device will start at the proper time (i.e. one hour earlier in the EET). But VDR gets confused by this and deletes the program running at 00.00-01.00, since there would seem to be an overlap. YLE channels are ok AFAICT. My guess is that this is an attempt by the broadcasters to work around buggy DVB recorders. Too bad I haven't got any other DVB devices beside my VDR, to see if it's the broadcasters or VDR... -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.15 on Gentoo: random and silent crash at startup
Hi, I finally did some testing and found out that the plugin to blame is the vdr control plugin. I disabled it since I don't really need it currently. But, just telling this here since this might help someone if they encounter the same problem =) - Ville 2008/2/23, Ville Aakko <[EMAIL PROTECTED]>: > Hi! > > Since VDR 1.5.10 (or thereabouts) VDR has had this weird problem - and > now that the 1.6 RC is near, I decided to report it (also I've been a > bit busy so I wouldn't had had the time to look into this before > myself). > > VDR dies at startup randomly, at around 5 seconds after the startup > (the Gentoo init script detects this fail, and so watchdog is newer > started). Just as randomly (~50% of the times) it start without errors > and is stable (as rock) in my working environment =). > > When it crashes, I can sometimes see the "Welcome to VDR" in my VFD, > sometimes even on the output of my DXR3 (if not always but I don't > have my TV turned on always), but right at that point the > gentoo-vdr-scripts decide they have waited enough. This could be a > gentoo-vdr-scripts bug, too. > > > btw., this is what I run in my root crontab to work around this: > START VDRpurkkakoira.sh > #!/bin/bash > > while true ; do > /etc/init.d/vdr start > if [ $? -gt 0 ] ; then ### punch the VDR > sleep 5s > else > sleep 30m > fi > done > END > This also works as an additional layer of a watchdog; hence the script > name =) Usually it needs 1-5 punches (but sometimes none). > > I believe some plugin is to blame. At VDR upgrade (when no plugin is > loaded as they usually need a recompile) VDR has never died this way. > I have my suspicions but I'm not going to tell them before I do some > more testing, to not to upset developers for nothing =) > > Here are my plugins: > dxr3 > femon > osdteletext > mplayer > undelete > streamdev-server > lcdproc > control > externalplayer > epgsearchonly > text2skin > epgsearch > quickepgsearch > burn > > So, I'm going to do some testing by disabling plugins, but in the > meantime, has anyone run into the same problem? Or does anyone have > any suggestions I should try? > > Also, I'll provide the syslog of my VDR in case someone is interested > - though it didn't provide anything to me that would tell why it fails > (and why it doesn't, when it doesn't). > > > - Ville > > > -- > Ville Aakko - [EMAIL PROTECTED] > -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
2008/3/10, Rolf Ahrenberg <[EMAIL PROTECTED]>: > On Sun, 9 Mar 2008, Luca Olivetti wrote: > > > I'm still using 1.0.4 (and, yes, from time to time I have osd problems > > with the dxr3), but a performance improvement could be actually a bad > > thing for the dxr3 (if it translates to more osd updates). > > > Well, in this case the performance improvement means less work for the > osd provider as I've eliminated unnecessary osd accesses. Hence the > lower CPU load on the xineliboutput setup. I didn't mention about those > tweaks in HISTORY, but they should be included in version 1.1.5 and a > few more in the next release. I tried skinsoppalusikka. It is a bit more stable, but not enough. Channel surfing and menus seem to be generally more stable. Editing, (putting marks and moving them), and most notably, jumping to a certain position via the red button is still PITA with skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit different when it starts being buggy; the "flickering" I get is different and it doesn't hang as often as it used to. So you can feel something has changed =). I still get more random crashes with skinsoppalusikka, than with text2skin. Also, skinsoppalusikka doesn't update the palette of channel logos, if the OSD isn't closed in between channel changes (this is notable only when channel surfing, but if you wait a while, let the OSD close itself, and then change channel, the logo is shown in right colors). Just for your information (it probably isn't worth the trouble to get skinsoppalusikka working properly on DXR3, unless you have some ideas what to try), and also for DXR3 users who are looking for a stable OSD. - Ville -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
2008/3/30, Rolf Ahrenberg <[EMAIL PROTECTED]>: > On Sun, 30 Mar 2008, Ville Aakko wrote: > > > Channel surfing and menus seem to be generally more stable. Editing, > > (putting marks and moving them), and most notably, jumping to a > > certain position via the red button is still PITA with > > skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit > > > Did you test it with the latest skinsoppalusikka-1.6.0? I added > similar osd performance tweaks for replay mode into that particular > version. No, sorry! I thoiught I was using the latesta, but I wasn't. But after some quick testing, it still seems unstable in the editing mode, > > Also, skinsoppalusikka doesn't update the palette of channel logos, if > > > Well, IMO the skin isn't responsible of palette updates, but the real > problem might be in the osd implemantation of DXR3 plugin. Yes, that is most probably true. I was merely stating what I'm experiencing with skinsoppaluskka and the logos =) - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
2008/3/31, Luca Olivetti <[EMAIL PROTECTED]>: > > channel logo *must* be disabled for the dxr3. But they look neat =) But, seriously, they work very nicely with text2skin here, and used to work in and older VDR / skinsoppalusikka, too (providing you use logos with decreased number of colours, but I really couldn't tell the difference when I opened both versions of some of the logos in an editor on my computer). So it IS a small regression (triggered in the plugin by changes in skinsoppalusikka). But the real problem here was the stability, into which the logos have no effect. Well, honestly, I didn't try the 1.6.0 without logos, but I assume this, because 1) disabling the channel logos didn't have any effect in a previous skinsoppalusikka, and 2) the instablility occurs in editing mode and when going trough the menus, i.e. NOT when any logos are shown on the screen. The "palette of the logos not updating" is, on the other hand, a very minor and purely cosmetic problem. - Ville -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
Seems that my brain stopped working in the middle of a sentence here : 2008/4/2, Ville Aakko <[EMAIL PROTECTED]>: > > No, sorry! I thoiught I was using the latesta, but I wasn't. But after > some quick testing, it still seems unstable in the editing mode, ... , but I need to do some more testing, before I can say if the 1.6.0 is more stable than 1.1.5. - Ville -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] lcdproc, utf-8 & VDR
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-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 - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] lcdproc, utf-8 & VDR
-- Forwarded message -- From: Ville Aakko <[EMAIL PROTECTED]> Date: 2008/6/17 Subject: Re: [vdr] lcdproc, utf-8 & VDR To: Hanno Zulla <[EMAIL PROTECTED]> 2008/6/17 Hanno Zulla <[EMAIL PROTECTED]>: > > 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 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 - [EMAIL PROTECTED] -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] lcdproc, utf-8 & VDR
2008/6/17 Matthias Becker <[EMAIL PROTECTED]>: > Is the "?"-mark comming from the conversion in VDR or is it due to > the fact, that the LCD cannot display the character in question? It's coming from the fact that the conversion is not done correctly. My LCD (or the driver) can output at least äöåÄÖÅ, and probably most diacretic characters, too - I believe it can output anything in iso-8859-1(5), and also does so (for channel info, EPG, menus etc...). Only the messages are not translated correctly (but something is done for them, since they are not shown in the usual 2-character garbage that you get when you display UTF-8 assuming it is some 8-bit-for-character set, but instead in ?-marks). We did quite extensive testing with Joachim (and I did some quite extensive testing, as described earlier in this thread, with my LCD). =) Regards, - VIlle -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] lcdproc, utf-8 & VDR
2008/6/18 Michael Brakemeier <[EMAIL PROTECTED]>: > 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 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 - [EMAIL PROTECTED] -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 576i output on DVI->HDMI?
2008/7/15 Jukka Vaisanen <[EMAIL PROTECTED]>: > My understanding is that 576i in HDMI is actually done as a 100Hz > displaymode where each frame is sent twice. This is because the HDMI > spec doesn't allow "speeds" as low as required by true 576i.. I'm not actually answering your question (I couldn't since I don't have any experience with these modern TVs), but, AFAIK, you wouldn't get very good results by doing what you describe. If every frame of 50Hz interlaced moving picture is shown twice, you'll get annoying blurriness and / or jerky movement. Anyhow, the movement won't be "smooth" as you might expect (because the frames are shown like this: 1-2-1-2-3-4-3-4-5-6-5-6-7-8-7-8 instead of 1-2-3-4-5-6-7-8). You'll get much better results by doing "true" deintercaling, and showing every "full" frame just once (i.e. 1+2-3+4-5+6-7+8 and so on). So what you want would be quite useless, IMHO, though I could be wrong. Someone correct me if you know better =). If you really want to show interlaced material as they are supposed to - i.e. you are a Hifi-lover - then the only "real" solution is to get a display that can (truly) show 50Hz interlaced - perhaps via a DXR3 card, as you used to =). > I am using xineliboutput currently as the software output device. Of > course I would prefer it to use 576i for only the interlaced SD channels > / recordings and change to 1080p for media player with HD content ;) I'd just deinterlace via software (or hardware), and then upscale x2 (576 * 2 = 1052). Or, maybe forget the upscaling and send 576p (n * 50Hz) trough the HDMI/DVI. -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 576i output on DVI->HDMI?
2008/7/15 Jukka Vaisanen <[EMAIL PROTECTED]>: > > Well the 100Hz is just a kludge to fit 576i on the HDMI signaling. My > understanding is that the following happens: > > PC sends 1-1-2-2-3-3-4-4.. but the a/v receiver just ignores every other > frame because it knows about the 576i kludge also.. so it is just seeing > 1+2-3+4 going into the deinterlacer + scaler. The 100Hz thing is just a > workaround to get enough data on the link so that the HDMI handshake will > happen :P I'd try to make a modeline: $ gtf 720 576 50 # 720x576 @ 50.00 Hz (GTF) hsync: 29.65 kHz; pclk: 26.57 MHz Modeline "720x576_50.00" 26.57 720 736 808 896 576 577 580 593 -HSync +Vsync $ gtf 720 576 100 # 720x576 @ 100.00 Hz (GTF) hsync: 61.10 kHz; pclk: 58.66 MHz Modeline "720x576_100.00" 58.66 720 760 840 960 576 577 580 611 -HSync +Vsync (if these blow up your 50'' fullHD plasma, you're on your own - try them at your own risk!) I'd suspect VDR+xinelibout would not support this out of the box. You probably need to make a script or something to change resolutions when needed. Also, xinelibout might not like resolution switches on the fly. But if this is the case, it could probably be worked around by making xinelibout / X part a frontend (I believe this is possible and a very common setup anyways), and restarting it when needed. OTOH, I don't see much gain in doing the above compared to the deinterlacing in software and then scaling, apart from saving some CPU cycles. I'd doubt any external display could do a better job, though then again, I haven't had any experience with those modern (post-4:3 CRT era TV) displays =) - Ville -- -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe, radeon x1200 and xv out
2008/7/15 Halim Sahin <[EMAIL PROTECTED]>: > This is the reason why I am trying to use fglrx. > Is there a chance to get this work with fglrx? If you didn't already try this - try disabling first AGPFastWrites (if the integrated is a PCIe divece inherently, it won't have any effect), and setting BusType "PCI" in xorg.conf. It won't give you good performance but just might make it more stable. -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
2009/1/6 Scott : > As Im just starting to get vdr working, I was wondering if 1:1 pixel mapping > between the video card (nvidia onboard HDMI output) and my flat panel > (Samsung plasma) is a waste of time. When looking at a "computer" generated > image like the desktop, its going to make a difference, but with broadcast > material (SD mostly), I imagine that the material is scaled anyway to fit > the resolution of the panel (which in my case I think is 1024x720, but that > has a bit of overscan). So it wont be 1:1 anyway, or am I wrong here?I > know this is a bit off topic, but there seems to be a fair bit of experience > here. I'd say it's not a waste of time. In general, it is a good idea to avoid any (unnecessary) processing. If you do not setup your video card to your display 1:1 to your panel's native resolution, you're most likely going to get an extra scaling of the video image (which is totally unnecessary and degrades the image). For example, if your panel is 1024 x 720, and your video card is setup for 1280 x 768, then you'd end up first scanling a PAL/NTSC/whatever video to the 1280 x 768 and then your panel is going to scale it to 1024 x 720. You'd get better results if you'll scale straight to the native resolution of the panel via the video card, or set the video card to the native resolution of the source material and let the panel do all the scaling. I don't know how to do the latter, and even if it is possible in all cases. In my setup, I have set up my video card to 1:1 to the panel I have (fullHD), since I have material in several different resolutions, and also use a desktop on my VDR box.It's more hassle free this way, if I would have chosen the latter case, then I would be constantly chancing resolution. It should be quite easy to setup 1:1 pixel mapping with any reasonably new display, video card and X.org, since the X.org uses EDID information quite well these days. Though, in practice, the DVB broadcasts are so much degraded by the mpeg compressing process at least here where I live, so it doesn't actually matter that much how you do the scaling ;=). YMMV. In any case, a (single) scaling process gives better results than 2 x a scaling process. -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
2009/1/6 : > >> I don't know how to do the latter, and even if it is possible in all >> cases. In my setup, I have set up my video card to 1:1 to the panel I >> have (fullHD), since I have material in several different resolutions, > > This is the theory. But you need to remember that you are using TV set as > a monitor, and typical TV sets, even FullHD ones implement overscan on HDMI > input. Some TVs disable overscan via special switch. Yes, you are right. On my Sony it is called "Täyskuiva" (in finnish), when I had not enabled it, thie TV did overscan IIRC. > But having overscan it means that having the 1:1 mapping is a bit harder. > You need to find out how much is the real visible resolution and define X- > screen to that resolution. I'm not sure what you mean by the above, surely you need to setup X to use the native resolution of the panel? Perhas you meant something different, as I did notice when I did my setup; that fgrlx (yuch, I'm an user of the dreadful fglrx) does a terrible underscan by default, becase it reports a larger screen area trough the HDMI that is actually used (?). I'd assume that nvidia, intel & perhaps some others do this better by default. It is beyond me why an ouput that is used for a digital display uses any kind of over/underscan, but that really was the case. Then I stumbled on this: <http://www.phoronix.com/forums/showthread.php?p=36734#post36734> And got 1:1 mapping at all refresh rates ever since. Thoguh, I still get terrible tearing - I've heard that the radeon driver should be better in video use, but I couldn't get it to work on my card, and I also need DRI... I should've bought nvidia, damn. I used a small program called lcdtest to test the 1:1 mapping. Believe when I say you do notice the difference =). Also I use a desktop and it is drawn exactly to the edges as it should be. -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Serial IR receiver + wakeup from suspend
2009/1/17 Alex Betis : > Hello all, > > I wonder if anybody here is using IR receiver that is connected to the PC > with 9-pin serial cable and is able to wake the machine from suspend mode? I use a IR-receiver which also connects to the power button header on the mainboard. It requires +5VSB (I took it from an USB header, since that was the only option available on my MB) to power the circuit. And of course the button that shorts the power button header is programmable. With this solution it doesn't matter what mode your computer is in, since pressing the power button is going to wake it from any mode. I got the receiver from: http://www.atric.de/ There are other implementations on the net, that have basicly the same idea. See Google! IIRC They are all so complicated that you are going to need a circuit board so unless you have the access to hardware required to make one, you need to buy a ready one or a DIY set. -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Serial IR receiver + wakeup from suspend
2009/1/17 Ville Aakko : > 2009/1/17 Alex Betis : >> Hello all, >> >> I wonder if anybody here is using IR receiver that is connected to the PC >> with 9-pin serial cable and is able to wake the machine from suspend mode? > > I use a IR-receiver which also connects to the power button header on > the mainboard. It requires +5VSB (I took it from an USB header, since > that was the only option available on my MB) Note that not all motherboards have +5VSB high in S5 (power off) in USB headers - some have it configurable, some don't. On my motherboard it is not configurable, but luckily it seems that all (or at least the one where I connected the +5VSB line) have it always high (I'd believe this is the case with most modern motherboards). This might matter if your motherboard doesn't have any headers having +5V in S5... but then of course you can always connect straight to the power supply, as in the instructions for the receiver I mentioned in my previous post =). BTW there's also an english manual on the site. -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Serial IR receiver + wakeup from suspend
2009/1/17 Nicolas Huillard : > Ville Aakko a écrit : >> BTW there's also an english manual on the site. > > I can't find it anywhere. Only german pages and manuals... > Do you have a link ? It's in the download section but here's a link anyways =) http://www.atric.de/IR-Einschalter/download/manual_en_rev4.pdf -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe + remote control
If I understood the issue correctly, Alex (the OP) has problems because the USB receiver gives BOTH kb events and makes a lirc device, and the KB events are not wanted and cause problems. I'd look in /dev/input to see which event device is the one for the KB side of the receiver and disable it; perhaps via Xorg.conf (I'd assume this is somehow possible). That would be a general solution for all software, including those that don't have an option for disabling keyboaard.But, as already stated by Jukka, vdr-sxfe already has one... but then maybe we didnt understand the issue correctly =) -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
Hi Scott! 2009/1/19 Scott Waye : > If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do > any de interlacing in xine, why is this not the same as what my digibox > does? I'm guessing it has something to do with xine outputting a > complete frame when the broadcast sends each field? What you state above is NOT correct. When you use your digiboxx, your TV panel does all interlacing and scaling. To do what your digibox does, you should alwways set the output in the same (interlaced) resolution as the broadast, NOT in the TV's native resolution. And no vertical scaling is allowed before deinterlacing! (but horizontal is allowed) Someone correct me if I'm wrong > What I'd hope > happen (for interlaced material) is that xine receives a field from VDR, > scales it to the X resolution (halfed vertically of course) and sends it > to the the graphics card which just passes it on to the TV which draws > that field. That doesn't seem to happen so where have I gone wrong? In changing the resolution. To achieve what you want, you need to set X to a PAL modeline (720 x 576 interlaced for PAL). However, this is not as straightforward for a VGA card as for full featured DVB cards or set tob boxes. Even after setting the right modeline, a few problems remain: 1) You need to enable sync on vblanck. 2) There is no way to automatically switch the resolution when/if the standard changes 3) The timigns are not exact on VGA (HDMI etc.) outputs The first is not possible on all drivers (i.e. fglrx). For the second problem there are no ready made solutions (but you can of course manually change between modes, and perhaps restart some sowftware when needed). For the third problem, see thread "RGB/PAL over VGA at variable frame rate" for more discussion and patches. Someone correct me if I'm wrong. -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
2009/1/20 Tony Houghton : > On Tue, 20 Jan 2009 18:19:49 +0200 > "Ville Aakko" wrote: > >> 1) You need to enable sync on vblanck. > > [Snip] > >> The first is not possible on all drivers (i.e. fglrx). > > Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have > APIs for waiting for vblank and ISTR seeing a xine option for vblank > sync with Xv. Do none of these work with fglrx? Nvidia's settings tool > has options to disable vblank sync for OpenGL and video, but I don't > know whether by setting it off it disables syncing altogether or by > setting it on it forces flip operations to automatically wait for > vblank. AFAIK this is a known issue with fglrx drivers. The API is there, but with fglrx the detection is (currently) broken, at least on 8.11 (which is what I'm using currently). I think I saw someone in some forum getting vsync working with fglrx but only for 'mplayer -vo gl'. But that was an exception- -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe from background script
Hi! 2009/2/20 Alex Betis : > Hi all, > > I wonder what am I doing wrong. > > The problem is that when this script is run in background (& at the end), > the job is shown as "stopped". > I've tried to run vdr-sxfe itself in background, it opens the window and the > job stops. > I know there is a switch that will run it in daemon mode, but that's not > that good for the script I want to have. I think I hit the problem you are having before, but in my current solution I do not need to face it. Currently, I log in automatically via kdm, which loads KDE (could be xfce or whatever you want, though I haven't tested because currently I want to use KDE) and automatically runs a script (~/.kde/Autostart/vdr-sxfe.sh) that starts vdr-sxfe. I don't background the vdr-sxfe.sh process in the script. I have two loops there; the second is in case vdr-sxfe crashes, to restart vdr-sxfe (vdr-sxfe doesn't do that anymore quite often) and the second is for suspend / resume (some parts of lirc/VFD don't like suspend on my setup). The latter waits from the start of suspend until end of resume to restart vdr-sxfe. And, also it looks for the errorlevel of vdr-sxfe ehwn it exits; if it is not a "clean" one, it assumes it was not initiated by the user (and allows automatic shutdowns). Do you really need to background vdr-sxfe the way you try to do it? On my setup, If I want to exit vdr-sxfe to use the desktop (actually, I don't need to do that but I can, also this disable automatic shutdowns on my setup via a kludge) I just press esc on my keyboard to shutdown vdr-sxfe (this leaves vdr running in the background). I have bound another button to restart vdr-sxfe again (to enable automatic shutdowns etc.). You could kill all running vdr-sxfe sessions whenever you run the script again (so that would actually work as a restart, too, Though, I don't need restarting vdr-sxfe, so I haven't done it). I can send my script if you need it. The rest might be offtopic or not, but I think in general your problem is related to a lack of documentation / examples / init scripts etc. needed when configuring VDR to display via X (as opposed to a full featured card or some other deticated output device that doesn't require X) At least for gentoo there are nice init sciŕipts and configuration files for VDR and its plugins. But it seems that the init scripts assume that a user has a full-featured card or another deticated ouput device for the TV. But if one needs X for the display instead (which more and more users will be using for several reasons), I'm still really in the dark how to do that elegantly. Not even the vdr-sxfe documentation had examples / ideas of ho to achieve the automation! I.e. I want to have a VDR showing the picture via HDMI without having to log in and running vdr-sxfe manually every time. The problem might actually lie in the several differen't use cases there are; some setup might only use the X for a deticated VDR, but some other users would need other software to run under the X session, too. In my case, I needed VDR to start automatically whenever I push the power button, but still have an easy way to switch to other prorams and / or desktop. Of course this is a complicated matter, as depending on the distribution / init scripts used, VDR might be run as root or a detidcated user 'vdr', but the additional software would not be run as such. I found the dilemma very confusing. So, I had sevveral questions but no ready solutions / answers; How should I start X.org / Which user should I run X as? Which user should run vdr-sxfe (or some other X output backend)? And if I'm not using a client/server setup, how on earth am I going to start an X session before the init scripts run VDR, to play along nicely with the init scripts? Do I need to log in as user 'vdr' (to start an X session) before running VDR? Is it possible to allow the VDR process (which is run as the user 'vdr') to connect to a X sessions, which is "owned" by a different user? Currently, I solved this via kdm's features and a script I made myself to run at the start of a session as a regular user, and chose vdr-sxfe to run as a client/server solution (this was the only solution I was able to run at all with the init scripts Gentoo came with). But I feel the script I made is really a dirty kludge =). So I see there might be a need for documentation and solutions / examples on this kind of setups (at least I didn't find any if there already are). Can anyone point into such documentation? Does anyone have any good personal examples? How do you run your VDR with an X11 output? Do you use the VDR box for other uses? If yes, how do you integrate the other applications? Hope this stirs some conversation =) -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where do you live and what kind of broadcast do you receive?
Country: Finland Transmission: DVB-C Encoding: MPEG-2 for SD. I haven't watched any HD channels although I have the hardware to display them. I don't watch that much TV, actually, now that I think of it. I like the setting up of a HDTV more than watching TV =) -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.7 branch and xineliboutput (on Gentoo)
Hi, I don't seem to get vdr-xineliboutput working at all on Gentoo. I used to have vdr-1.6 branch with xineliboutput. Live TV was OK, but recordings were just unwatchable (vdr-sxfe losing the connection all the time, rewinding being a PITA etc..). So, I've used Mplayer to play those, and VDR just as a recording server. But this was very annoying, so I decided to upgrade to vdr-1.7 and try the vdr-xineliboutput cvs plugin, to see if it would work better. (I'm an ATI user, but judging from the symptoms, I suspect there was something very wrong with my installation, not jsut ATI-related problems). But, now, I don't get a connection to the vdr-xineliboutput server at all! I just get the "No Signal" picture. Has anyonve on Gentoo got this working? I'm using the vdr-devel repository in addition to stock portage. I have installed: vdr-1.7.14-r1 (from vdr-devel) xine-lib-1.1.18.1 vdr-xineliboutput- (the CVS ebuild from Gentoo portage). I see the bug report at <http://bugs.gentoo.org/show_bug.cgi?id=296042>. But it is inclear to me whether the ebuild in portage is updated or not... I will compare and see of course, but decided to post here to get some input from fellow users =) Here's vdr-sxfe output. I'm running vdr-sxfe as a regular user (I've never got the local pipes working, anyone got an idea how / where to set the permissions?). # vdr-sxfe --fullscreen --video=opengl --audio=alsa:phononpulse 127.0.0.1 vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.18, using xine-lib 1.1.18) Fullscreen mode Video driver: opengl Audio driver: alsa Audio device: phononpulse VDR Server: 127.0.0.1 [11727] [vdr-fe]Error: The name org.gnome.ScreenSaver was not provided by any .service files [11727] [vdr-fe] (ERROR (tools/gnome_screensaver.c,126): Resource temporarily unavailable) [11727] [vdr-fe]Detected 2 CPUs [11727] [vdr-fe]Enabling FFmpeg multithreaded video decoding [11727] [input_vdr] Connecting (control) to tcp://127.0.0.1:37890 ... [11727] [input_vdr] Server greeting: VDR-1.7.14 xineliboutput-1.0.90-cvs READY [11727] [input_vdr] Connected (control) to tcp://127.0.0.1:37890 [11727] [input_vdr] Connecting (data) to pipe:///etc/vdr/plugins/xineliboutput/pipes.11591/pipe.0 [11727] [input_vdr] Pipe opening failed [11727] [input_vdr](ERROR (xine_input_vdr.c,5499): Permission denied) [11727] [input_vdr] Data stream connection failed (PIPE) [11727] [input_vdr] Connecting (data) to rtp://@224.0.1.9:37890 ... [11727] [input_vdr] Received UDP/RTP multicast from unknown sender: 192.168.0.3:51915 [11727] [input_vdr] Received UDP/RTP multicast from unknown sender: 192.168.0.3:51915 [11727] [input_vdr] Received UDP/RTP multicast from unknown sender: 192.168.0.3:51915 [11727] [input_vdr] Received UDP/RTP multicast from unknown sender: 192.168.0.3:51915 [11727] [input_vdr] Data stream connection failed (RTP) [11727] [input_vdr] Connecting (data) to udp://127.0.0.1 ... [11727] [input_vdr] Data stream connected (UDP) [11727] [input_vdr] WARNING: xine-engine setting "engine.buffers.audio_num_buffers":230 istoo low for HD-playback! Please use values between 500-1000! [11727] [input_vdr] WARNING: Video output driver reports it does not support unscaled overlays ! [11727] [demux_vdr] Using decoder "libmpeg2" for mpeg2 video [11727] [demux_vdr] Using decoder "FFmpeg" for H.264 video WARNING: MRL does not start with 'xvdr:' (127.0.0.1) Press Esc to exit post_warp: warp_get_parameters post_warp: warp_get_parameters post_warp: warp_get_parameters post_warp: warp_get_parameters post_warp: warp_set_parameters: output_width=0, output_height=0, output_aspect=0.000, no_downscaling=0 post_warp: warp_get_parameters post_warp: warp_set_parameters: output_width=720, output_height=0, output_aspect=0.000, no_downscaling=0 post_warp: warp_get_parameters post_warp: warp_set_parameters: output_width=720, output_height=576, output_aspect=0.000, no_downscaling=0 post_warp: warp_get_parameters post_warp: warp_set_parameters: output_width=720, output_height=576, output_aspect=0.000, no_downscaling=1 post_warp: warp_get_parameters post_warp: dispose post_warp: dispose [11727] [input_vdr] Connections closed. Terminating... [11727] [vdr-fe]Error: The name org.gnome.ScreenSaver was not provided by any .service files [11727] [vdr-fe] (ERROR (tools/gnome_screensaver.c,126): Resource temporarily unavailable) -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)
2010/5/16 Ville Aakko : > But, now, I don't get a connection to the vdr-xineliboutput server at > all! I just get the "No Signal" picture. Has anyonve on Gentoo got > this working? My bad! I had installed a dxr3 card back to my computer, in order to get at least one well working output for VDR, and enabled the plugin, and forgot to disable that... because I had both dxr3 plugin and xineliboutput enabled, VDR thought the dxr3 is the primary device and send nothing to the xineliboutput frontend... I think =). At least it works now, that I disabled the dxr3. Thanks for Halim, anyways. With the 1.7 branch and CVS xineliboutput, the opengl output is unusable (with the 1.6 branch / 1.0.4_p20091118 xineliboutput opengl was the most usable output). SDL, and XV work well, and even recordings now seem to work! However, The OSD is very ugly! Seems like everything in the OSD is scaled to 512x384 or something, that of course looks terrible on a FullHD 40" LCD. The problem here is, of course, that with ATI, you can't use the hud OSD (the picture get's blanked then, although the OSD would look very nice then) ... in the CVS the non-HUD OSD is very ugly. Well, at least now this is usable altough with a very ugly OSD, but I guess I can live with that for time being. If there are any tips for getting this working better, they are welcome =). -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)
2010/5/16 Ville Aakko : > Well, at least now this is usable altough with a very ugly OSD, but I > guess I can live with that for time being. If there are any tips for > getting this working better, they are welcome =). I'll have to add, that all the xineliboutput configuration settings are missing from the VDR menu (Menu -> Settings -> Plugins: There is no xineliboutput menu anymore!). Is this normal? Cheers! - Ville -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)
Hi! I enabled compositing in KDE, and surprisingly, I get very smooth playback AND a working HUD OSD with xv or sdl! Nice =) With opengl either the TV picture is black and there is OSD, or the OSD is not shown at all. So OpenGL output is not usable... Also, the problems with opengl not being usable, was because I had no "xvdr+tcp://" in front of localhost in my command line for vdr-sxfe (instead, I used them at first when trying out sdl and xv... if I omit them, it is exactly as unusable with xv and sdl as with opengl), Now, if anyone can tell me where are all the DVB subtitles (they are gonce since this upgrade) and the xineliboutput menus, this would be perfect =) Cheers! -Ville -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe crashing all the time
Hi Martti, 2010/5/4 Martti Kuparinen : > 04.05.2010 15:32, Mr. Tux kirjoitti: >> >> Hello Martti >> >> Please add the following two lines in ~./.xine/config to enable OSD with >> opengl: >> >> video.driver:opengl >> video.output.opengl_renderer:2D_Tex > > This works too, but the OSD fonts are still ugly... You might wan't to try to enable compositing in x.org. This was the culprit for me, although the hud OSD was unusable for me. I have the exact same hardware (well, HD3200 at least - Gigabyte GA-MA78GM-S2H), but I read you switched to the open source driver, I'm still on fglrx. Also, I'm using Gentoo. May this post be of much use! - Ville -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)
2010/5/20 Ville Aakko : > Now, if anyone can tell me where are all the DVB subtitles (they are > gonce since this upgrade) and the xineliboutput menus, this would be > perfect =) Now, if someone is wondering what I'm trying to say above, is that the DVB subtitles were gone since the upgrade (to VDR-1.7 and cvs xineliboutput), as well as the xineliboutput menus =). Although, "gonce" might be a nice composite word for "gone since" =) - Ville -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OSD not working
2010/5/31 James Courtier-Dutton : > Hi, > > I am using vdr 1.7.14. > I cannot see an OSD menu when using the vdr-sxfe client. Are you using an ATI card? Or some other card with bad drivers? With the fglrx driver, the HUD OSD does not work (except, that with the most recent drivers, 9.4 and 9.5, I get HUD OSD if I enable compositing). Cheers, Ville -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] missing dvb subtitles in records
2007/1/7, Arthur Konovalov <[EMAIL PROTECTED]>: Hi. I noticed that dvb subtitles not recorded with video. Can anyone confirm that it works? Hi, I have a similar setup and yes, DVB subtitles are recorded. I don't use ttxtsubs at all (only the DVB ones). However, I have noticed that recently, on some recordings, there are long pauses for subtitles (1-5 minutes, haven't taken time actually) and then suddenly all (?) subtitles that should have been shown previously are shown for about 0.1s each, and then subtitles resume normally. More specifically, I had this problem with Cold Lazarus series that I recorded from YLE Teema on 28.12.2006, and possibly with some others IIRC. But it doesn't bother me much, so I didn't note which recording it was. This is similar to the behavior I have always got when I jump in a recording with dvb subtitles, but then the pause is usually ~30s, max. 1 minute. It is as if the subtitles are in blocks and displaying them can only resume at the end/start of a block. My environment: Slackware-11.0, kernel 1.6.19, vdr-1.4.4-3 with vdr-1.4.4-liemikuutio-1.13.diff, vdr-1.4.4-subtitles-0.4.0-and-ttxtsubs-0.0.5.diff I have : - Gentoo - kernel 2.6.19 - probably you too ;) - VDR 1.4.4_p2 - skinelchi - subtitles-0.4.0 - (and ttxtsubs-0.0.5_p2, but I don't use them) - loads of other plugin, for example dxr3 ProjectX demux not detect dvb subtitles too. I have never tried projectX or any other means to convert the recordings made by VDR to other formats. But I'd guess this could be a ProjectX issue, but if VDR can't replay subtitles from your recording, then theres something wrong with your setup (a missing patch or something). I strongly recommend using Gentoo for VDR. -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
