[manül]

I want to report back this bug. i reported it months ago but i didn't use the tool until now so i didn't check and report back about it until now.
It's still there even with the latest version of your tool.
here's the log:
http://pastie.org/private/5duzg0e1vaugax12qqsddw

I won't be at home until sunday evening but I'm sure you are not using the latest version (plus: your log is truncated).

Your log:

Code:

NOTICE: AddOnLog: DVBViewer Client: Dvb::Open - Hostname: '127.0.0.1'

Current code:

Code:

XBMC->Log(LOG_DEBUG, "Hostname:   %s", g_strHostname.c_str());

will produce:

Code:

DEBUG: AddOnLog: DVBViewer Client: Hostname:   127.0.0.1

In fact your log line is from another file and has been removed since 6 months. See https://github.com/manuelm/xbmc-pvr-addo...d05#L1L129

[phate89]

I want to report back this bug. i reported it months ago but i didn't use the tool until now so i didn't check and report back about it until now.
It's still there even with the latest version of your tool.
here's the log:
http://pastie.org/private/5duzg0e1vaugax12qqsddw

I won't be at home until sunday evening but I'm sure you are not using the latest version (plus: your log is truncated).

Your log:

Code:

NOTICE: AddOnLog: DVBViewer Client: Dvb::Open - Hostname: '127.0.0.1'

Current code:

Code:

XBMC->Log(LOG_DEBUG, "Hostname:   %s", g_strHostname.c_str());

will produce:

Code:

DEBUG: AddOnLog: DVBViewer Client: Hostname:   127.0.0.1

In fact your log line is from another file and has been removed since 6 months. See https://github.com/manuelm/xbmc-pvr-addo...d05#L1L129

You're definitely right. I copy the log from the home server instead of the remote computer that connects to dvbviewer with the updated version -.-
Sorry for that.
Here's the full (debug enabled) log (of course i confirm the bug is still there):
http://xbmclogs.com/show.php?id=53048

[strangerranger]

Hi!

I just upgraded from 1.6.9 to 1.6.10, here is my feedback:
Channel logos are now complete -> great!
Channel loading time is excellent (timeshift disabled) -> great!

I am having one issue with some channels: they fail to load. It is possible that this issue existed previously and I just did not use those channels.
For example, Arte fails to load and XBMC is unresponsive until a timeout stops the channel loading.

Here is my log:
http://xbmclogs.com/show.php?id=53197
Can you find a problem in there?

Cheers and thanks for the continous improvement,

strangerranger

[manül]

Here's the full (debug enabled) log (of course i confirm the bug is still there):
http://xbmclogs.com/show.php?id=53048

Looks like a bug in your theme aeon.nox. The name/title of the timer is displayed in the channel-column *AND* in the title-column.
And I'm not able to reproduce this with the default theme.

I am having one issue with some channels: they fail to load. It is possible that this issue existed previously and I just did not use those channels.
For example, Arte fails to load and XBMC is unresponsive until a timeout stops the channel loading.

Here is my log:
http://xbmclogs.com/show.php?id=53197
Can you find a problem in there?

Log looks fine except that ffmpeg couldn't decode the stream which results in your described behavior. This might have multiple reason:
- The channel doesn't work at all. You can easily verify this by watching via RS Webinterface
- RS didn't send data/something internal (ffmpeg/xbmc related) got fucked. I sometimes get this too. And the only way to solve this is to tune into another channel (doesn't matter which) and tune back.
- probably more I just can't think off

[babesumitra]

I have found a Bug. When XBMC is started under a proxy server the addon does not start unfortunately. Is there a solution for this?

[wzabel]

By trying to install the addon on a Linux/Arm device, the addon can not be loaded. The XBMC log tells:

/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

My XBMC build seemes to use an other version.

To solve this little problem I compiled the source from 'https://github.com/manuelm/xbmc-pvr-addons' on my development System, X86 Debian, but 'make zip' only produces the linux-i486-version. What must been changed to make linux-arm-Versions?
Thanks a lot!

Meanwhile compiling was succesful. I called

./configure --host=arm--linux

.
But the problem still remains the same. After installing the addon could not be loaded:

ERROR: Unable to load /root/.xbmc/addons/pvr.dvbviewer/XBMC_dvbviewer.pvr, reason: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /root/.xbmc/addons/pvr.dvbviewer/XBMC_dvbviewer.pvr)

Any suggestions?

[strangerranger]

Log looks fine except that ffmpeg couldn't decode the stream which results in your described behavior. This might have multiple reason:
- The channel doesn't work at all. You can easily verify this by watching via RS Webinterface
- RS didn't send data/something internal (ffmpeg/xbmc related) got fucked. I sometimes get this too. And the only way to solve this is to tune into another channel (doesn't matter which) and tune back.
- probably more I just can't think off

You are right: those channels work at DVB-Viewer but fail to start via recording service (e.g. streaming via webinterface). I will have to find out what the problem is there.

Thanks for your quick reply!

[phate89]

Here's the full (debug enabled) log (of course i confirm the bug is still there):
http://xbmclogs.com/show.php?id=53048

Looks like a bug in your theme aeon.nox. The name/title of the timer is displayed in the channel-column *AND* in the title-column.
And I'm not able to reproduce this with the default theme.

I switched to confluence and it is still there...
And if i try to add the timer for the first channel in the list it gives me this error in the log:

Code:

21:46:41 T:5988   ERROR: PVRTimers - PVR::CPVRTimers::AddTimer - no channel given

[manül]

By trying to install the addon on a Linux/Arm device, the addon can not be loaded. The XBMC log tells:

/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

My XBMC build seemes to use an other version.

The message is telling you your libstdc++/gcc is too old. I'm cross-compiling with crosstool-ng 1.18.0 and it's default gcc version 4.7.3.

To solve this little problem I compiled the source from 'https://github.com/manuelm/xbmc-pvr-addons' on my development System, X86 Debian, but 'make zip' only produces the linux-i486-version. What must been changed to make linux-arm-Versions?
Thanks a lot!

Meanwhile compiling was succesful. I called

./configure --host=arm--linux

.
But the problem still remains the same. After installing the addon could not be loaded:

ERROR: Unable to load /root/.xbmc/addons/pvr.dvbviewer/XBMC_dvbviewer.pvr, reason: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /root/.xbmc/addons/pvr.dvbviewer/XBMC_dvbviewer.pvr)

Any suggestions?

You haven't set up a cross-compile toolchain. Use crosstool-ng. It's really easy (compared to the manual steps).
And you'll have to use --host=arm-unknown-linux-gnueabi

---

I have found a Bug. When XBMC is started under a proxy server the addon does not start unfortunately. Is there a solution for this?

I wouldn't call this a real bug. The plugin is using methods provided by XBMC to fetch HTTP sites. XBMC is using libcurl. Hence libcurl tries to communicate with the RS using the specified proxy. There's no UI to specify proxy exceptions but libcurl supports environment variables.

Environment Variables

libcurl automatically checks and uses a set of environment variables to know what proxies to use for certain protocols. The names of the variables are following an ancient de facto standard and are built up as "[protocol]_proxy" (note the lower casing). Which makes the variable 'http_proxy' checked for a name of a proxy to use when the input URL is HTTP. Following the same rule, the variable named 'ftp_proxy' is checked for FTP URLs. Again, the proxies are always HTTP proxies, the different names of the variables simply allows different HTTP proxies to be used.

The proxy environment variable contents should be in the format "[protocol://][user:password@]machine[:port]". Where the protocol:// part is simply ignored if present (so http://proxy and bluerk://proxy will do the same) and the optional port number specifies on which port the proxy operates on the host. If not specified, the internal default port number will be used and that is most likely *not* the one you would like it to be.

There are two special environment variables. 'all_proxy' is what sets proxy for any URL in case the protocol specific variable wasn't set, and 'no_proxy' defines a list of hosts that should not use a proxy even though a variable may say so. If 'no_proxy' is a plain asterisk ("*") it matches all hosts.

from http://curl.haxx.se/libcurl/c/libcurl-tutorial.html

[Klaus Heynen]

So far the plug-in works fine for me on a Raspberry Pi B but the loading times for the Channels, EPG and in particular the Recordings (> 5500 items) take simply too long with the plug-in provided as is (incl. in the openelec distribution).

Apart from that it is a gear plug-in and very usefull, a great piece of work!

Is the any chance to get an up-dated version for Raspberry Pi which does not each and every time you access an Menue item download the whole thing again from the server or anyway quicker?


Best regards


Klaus

[manül]

So far the plug-in works fine for me on a Raspberry Pi B but the loading times for the Channels, EPG and in particular the Recordings (> 5500 items) take simply too long with the plug-in provided as is (incl. in the openelec distribution).

Use favourites. Either a local or the remote one.

[Klaus Heynen]

Does that improve also the speed of diplaying Recordings which is my biggest head ache?

[manül]

Does that improve also the speed of diplaying Recordings which is my biggest head ache?

No. Just epg loading as the channel list is a lot smaller.

[omnium]

..in particular the Recordings (> 5500 items) take simply too long with the plug-in..

..with thumbnails?

http://forum.xbmc.org/showthread.php?tid...pid1224678

0.1.7
.
[added] Don't fetch recording thumbnails at startup if there are more than 20 recordings.
.

to speed up...things aren't what they used to be/previously, everything was better.

[manül]

..in particular the Recordings (> 5500 items) take simply too long with the plug-in..

..with thumbnails?

http://forum.xbmc.org/showthread.php?tid...pid1224678

0.1.7
.
[added] Don't fetch recording thumbnails at startup if there are more than 20 recordings.
.

to speed up...things aren't what they used to be/previously, everything was better.

This isn't necessary any more. In old RS API the thumbnail needed an additional HTTP lookup just to get the URL to the recording image. This additional HTTP lookup was very slow, so A600 limited this to 20 and cached the results. Since RS 1.24 (or so) RS does provide the URL directly, so I've removed this.

I'm sorry but this isn't really a bug of the plugin. XBMC should either implement paging so you can only see about 100 recordings or you should just delete/move some recordings. >5000 recordings + images are just too many for the slow raspi.