[margro]

The Milhouse Gotham builds for the Raspberry Pi contain the modifications for faster channel switching. I don't know if they are also included in the Rbej builds.

[dogboy]

well… it seems that was a remarkable improvement, but I didn't have any picture. I will keep working on it. Any tips as to a "stable" version? I just went for the 22-01 release, which is a bit bleeding edge. This is with an RPi 512mb and VU+ Solo2 box, using ViX 3.0.808.

Build used is "OpenELEC-RPi.arm-devel-20140122135243-r17116-gc79f518"

My observations...

HD zapping in under 10 seconds [no video though, but I'm sure I can fix that] - audio comes through within 10 sec
Crashed on channel change [HD to HD]
Video only present on occasion [only on one channel in fact]
Occasional crashes, when changing channels
No glitching in the video
Video is interlaced
Lightning fast channel/EPG import

If there was a Frodo build that included these changes…?

[popcornmix]

well… it seems that was a remarkable improvement, but I didn't have any picture. I will keep working on it. Any tips as to a "stable" version? I just went for the 22-01 release, which is a bit bleeding edge. This is with an RPi

Debug log?

[dogboy]

>Debug log?

I don't have this enabled, but will do now. I just did a clean install [using Linux] rather than an update but the problems persist. Pretty much no image, but audio in <10s with buffer indicator. Crashes after a couple of channel changes HD to HD.

[dogboy]

here is the log

http://xbmclogs.com/show.php?id=114559

not managed to get any video at all [SD or HD] since the fresh install. Audio is OK on HD, no audio on SD. I have edited the config.txt to include my mpeg2 licence [just verified, to be sure]

Crashes when zapping [not every time, mind] , although there were a few instances when it jumped back to the channel list rather than zapping.

If this had worked [!] it would be the fastest zap experience I've had by far, which is encouraging. Thank you for taking the time to look at it.

Nick

[popcornmix]

http://xbmclogs.com/show.php?id=114559

You've configured dvdplayer as default media player which is currently very experimental. I think you should change back to omxplayer.
If you do want to test dvdplayer, I'd suggest increasing gpu_mem to 256 as it requires more gpu memory than omxplayer.

I didn't see any evidence of you trying to play video from this log, so no clues as to exactly what is failing.

[dogboy]

mmm… apologies, I'm pretty new to this, and although I can manage basic compiling [and following Linux instructions] I would need some guidance as to how to rectify this…. is there an easy way to switch to omxplayer without recompiling my own version. If you guys or Milhouse have a version that uses omxplayer, please let me know.

Maybe that's the reason the zap is so fast… no video. TBH it crashes every 5 minutes, so even if it worked it'd be hopelessly unstable.

Anyways, my intention had been to use the Pi as a TV extender, but I gold hold of an additional Vu+ box. This is pretty mental, I load up an enigma2 plugin called Remotechannelstreamconverter - https://github.com/E2OpenPlugins/e2openp...mConverter - and this takes the IP of the "host" box, with the tuners and downloads the bouquets and epg.

The zap speed on this "client" box is in the order of milliseconds. Is this due to specific hardware contained on the box [hardware video decoding etc] that simply isn't available on the Pi?

One more thing - popcorn mix, do your builds include fast zapping?

Thanks a million for the support…

Nick

[popcornmix]

mmm… apologies, I'm pretty new to this, and although I can manage basic compiling [and following Linux instructions] I would need some guidance as to how to rectify this…. is there an easy way to switch to omxplayer without recompiling my own version. If you guys or Milhouse have a version that uses omxplayer, please let me know.

Ah - the recent Milhouse builds had unintentionally made dvdplayer the default player. You can override that in advancedsettings.xml, or perhaps easier get the latest version:
http://forum.xbmc.org/showthread.php?tid...pid1609294
which had made omxplayer the default again.

[jdembski]

The zap speed on this "client" box is in the order of milliseconds. Is this due to specific hardware contained on the box [hardware video decoding etc] that simply isn't available on the Pi?

Even on powerfull systems the channel switch takes a couple of seconds with the VU+-addon. The addon doesn't have its own demuxer, but just hands over the streaming URL to XBMC. From what I understood this is what is causing the channel switching times...

What I don't understand: Surly addons like the htsp, vnsi or other addons are feeding XBMC the ts-streams received from the DVB device, so why isn't it possible to have fast channel switching with the XBMC internal demuxer, too? Or maybe it is, but need some changes in the code of the PVR-addon?

[FernetMenta]

Surly addons like the htsp, vnsi or other addons are feeding XBMC the ts-streams received from the DVB device, so why isn't it possible to have fast channel switching with the XBMC internal demuxer, too?

vnsi and tv headend don't feed the ts stream, they have their own parsers and demuxer

[dogboy]

I have to be honest, I'm pretty far out my depth here, but I can experiment and test things with the setup I have [1x Vu+ solo2, 1x Vu+ solo [on LAN, no tuner] and 1x R-Pi]. I also have a MacPro [12 core, 64gb] running gotham and/or frodo. The Mac Pro is the least reliable of the setups zappiis still in excess of 5 seconds on the Mac Pro, but 35seconds plus on the Pi, it does seem crazy.

I'm gonna try the milhouse build with OMX now.

FWIW, I don't think these boxes have a ridiculous spec, the client box is a vu+solo… there is *nothing* extra happening on the "host" box, I didn't need to install any plugins or nothing…

333mhz mips
256mb ram

[dogboy]

that milhouse build [24-1] works much better, 2 second zap between HD channels, 10 seconds between SD channels, but possible a bit inconsistent. It did crash immediately after install logs are here

http://xbmclogs.com/show.php?id=115158

---

plus, it shows the visualiser between zaps...

[popcornmix]

http://xbmclogs.com/show.php?id=115158

Lots of errors in log:

Code:

13:29:30 294.946442 T:2872046672   ERROR: Open - Error opening http://10.0.1.2:80/web/epgservice?sRef=1%3A0%3A1%3A2540%3A81A%3A2%3A11A0000%3A0%3A0%3A0%3A
13:29:30 294.948730 T:2872046672   DEBUG: AddOnLog: VU+ / Enigma2 Client: GetHttpXML - Could not open webAPI.
13:29:30 294.949036 T:2872046672   DEBUG: AddOnLog: VU+ / Enigma2 Client: Unable to parse XML: Error document empty. at line 0
13:29:30 294.949249 T:2872046672   ERROR: PVR - GetEPGForChannel - addon 'solo2:10.0.1.2' returned an error: server error
13:29:30 294.949463 T:2872046672   ERROR: PVR - GetEPGForChannel - cannot get EPG for channel 'Sangat' from client '1': server error
13:29:30 294.949646 T:2872046672   ERROR: EPG - Update - failed to update table 'Sangat'
13:29:30 294.954041 T:2872046672   DEBUG: EPG - UpdateFromScraper - updating EPG for channel 'Aastha' from client '1'
13:29:30 294.954590 T:2872046672    INFO: AddOnLog: VU+ / Enigma2 Client: GetHttpXML Open webAPI with URL: 'http://10.0.1.2:80/web/epgservice?sRef=1%3A0%3A1%3AD7AC%3A900%3A2%3A11A0000%3A0%3A0%3A0%3A'
13:29:30 294.956390 T:2872046672   DEBUG: CFileCache::Open - opening <web/epgservice> using cache
13:29:30 294.964172 T:2872046672   ERROR: Open - Unhandled exception

Looks like PVR backend may have crashed, but that's not really something I know about.

[dogboy]

I'm using an image called ViX which is based on PLi, there is a chance that the backend isn't as prescribed [it stipulates openPLi].

However, I can't switch over to PLi for testing purposes, as my family's TV experience would fall over completely

[LSU Jonno]

I realize I'm preaching to the choir, but isn't "slow channel changes" a bug from Frodo? It shouldn't matter that we haven't made the Gotham feature freeze. We are fixing a bug.