Hello
I'm using vdr 2.0.1 on Debian (with Debian package) and xineliboutput (also provided by Debian).
I can connect xine on vdr, but once I hit 'ESC' to get the main menu, vdr segfaults.
Here's the backtrace:
Core was generated by `/usr/bin/vdr -v /mnt/video2/vdr -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004eee4f in cSkinLCARSDisplayMenu::DrawLive (this=0x21c1c70, Channel=0x0) at skinlcars.c:1344
warning: Source file is more recent than executable. 1344 osd->DrawText(xa00, yt00, itoa(Channel->Number()), Theme.Color(clrChannelFrameFg), Theme.Color(clrChannelFrameBg), tallFont, xa02 - xa00, yt02 - yt00, taTop | taRight | taBorder); (gdb) bt #0 0x00000000004eee4f in cSkinLCARSDisplayMenu::DrawLive (this=0x21c1c70, Channel=0x0) at skinlcars.c:1344 #1 0x00000000004ef0f2 in cSkinLCARSDisplayMenu::Flush (this=0x21c1c70) at skinlcars.c:1659 #2 0x00000000004a5124 in cInterface::GetKey (this=0x21788e0, Wait=true) at interface.c:35 #3 0x00000000004732d5 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1016
Note that I've found this message in my logs:
[xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Since the theme colors looks like they are specified as ARGB, this may hint at a problem there.
Feel free to get back to me if you need further information.
All the best
On 18.05.2013 17:49, Dominique Dumont wrote:
Hello
I'm using vdr 2.0.1 on Debian (with Debian package) and xineliboutput (also provided by Debian).
I can connect xine on vdr, but once I hit 'ESC' to get the main menu, vdr segfaults.
Here's the backtrace:
Core was generated by `/usr/bin/vdr -v /mnt/video2/vdr -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004eee4f in cSkinLCARSDisplayMenu::DrawLive (this=0x21c1c70, Channel=0x0) at skinlcars.c:1344
warning: Source file is more recent than executable. 1344 osd->DrawText(xa00, yt00, itoa(Channel->Number()), Theme.Color(clrChannelFrameFg), Theme.Color(clrChannelFrameBg), tallFont, xa02 - xa00, yt02 - yt00, taTop | taRight | taBorder); (gdb) bt #0 0x00000000004eee4f in cSkinLCARSDisplayMenu::DrawLive (this=0x21c1c70, Channel=0x0) at skinlcars.c:1344 #1 0x00000000004ef0f2 in cSkinLCARSDisplayMenu::Flush (this=0x21c1c70) at skinlcars.c:1659 #2 0x00000000004a5124 in cInterface::GetKey (this=0x21788e0, Wait=true) at interface.c:35 #3 0x00000000004732d5 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1016
Note that I've found this message in my logs:
[xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Since the theme colors looks like they are specified as ARGB, this may hint at a problem there.
The problem appears to be that there is no current channel. I don't know how this could happen on your system, because normally there always is s current channel. However, you could try adding these lines to skinlcars.c in function cSkinLCARSDisplayMenu::DrawLive():
DrawMainFrameUpper(Theme.Color(clrChannelFrameBg)); osd->DrawText(xd00, yd00, tr("LIVE"), Theme.Color(clrChannelFrameBg), Theme.Color(clrBackground), tallFont, xd07 - xd00, yd01 - yd00, taTop | taRight | taBorder); } + if (!Channel) + return; if (initial || Channel != lastChannel) { osd->DrawText(xa00, yt00, itoa(Channel->Number()), Theme.Color(clrChannelFrameFg), Theme.Color(clrChannelFrameBg), tallFont, xa02 - xa00, yt02 - yt00, taTop | taRight | taBorder); osd->DrawText(xa03, yt00, Channel->Name(), Theme.Color(clrChannelName), Theme.Color(clrBackground), tallFont, xd00 - xa03, yd01 - yd00, taTop | taLeft);
Klaus
Le Sunday 19 May 2013 11:54:14, Klaus Schmidinger a écrit :
The problem appears to be that there is no current channel. I don't know how this could happen on your system, because normally there always is s current channel.
Indeed. After a file system full on my system, I ended up with an empty channel.conf. Which may explain the missing current channel.
Now that I've restored channel.conf, everything is back to normal.
Well, I still have a minor issue: FR3 DVB-T channel is broadcast as 544x576. It's a 16/9 program displayed as 1024x576. In this case, vdr's menu is stretched horizontally and the right part (with the DVB device status) is off screen.
Thanks a bunch for the help.
Dominique
Le Sunday 19 May 2013 18:12:30, Dominique Dumont a écrit :
I still have a minor issue: FR3 DVB-T channel is broadcast as 544x576. It's a 16/9 program displayed as 1024x576. In this case, vdr's menu is stretched horizontally and the right part (with the DVB device status) is off screen.
I've mitigated the problem by playing with display parameters (font size, width and left margin). Most menu are readable.
Only the configuration menu is hard to use: parameters values are still off screen.
well, I can live with this if this problem too hard to solve.
All the best
Dominique
On 19.05.2013 18:31, Dominique Dumont wrote:
Le Sunday 19 May 2013 18:12:30, Dominique Dumont a écrit :
I still have a minor issue: FR3 DVB-T channel is broadcast as 544x576. It's a 16/9 program displayed as 1024x576. In this case, vdr's menu is stretched horizontally and the right part (with the DVB device status) is off screen.
I've mitigated the problem by playing with display parameters (font size, width and left margin). Most menu are readable.
Only the configuration menu is hard to use: parameters values are still off screen.
well, I can live with this if this problem too hard to solve.
I assume that this is a problem of your output plugin, which doesn't provide a suitable OSD size in its GetOsdSize() function.
Klaus