[popcornmix]

Overall I am extremely impressed and want to give my appreciation and admiration to those who have contributed to take the build I tried to where it is today. Please let me know what I can do to help and also if you have any ideas as to my buffering issue.

Being able to build from source is useful.
http://wiki.openelec.tv/index.php?title=...spberry_Pi

It means you can run experiments with and without new patches to narrow down where problems appeares.
Methodical testing of new builds is useful.

Being told a specific new patch makes buffering over NFS worse with H264 and DTS passthough is useful information.
Being told buffering is worse now that it was a few months back is not so helpful.

There's a post in this thread from me to Milhouse describing the numbers in the codec info overlay and how they relate to cpu based underrun, and file I/O underrun.
Would be worth reading that if you can find it.

[theneverstill]

Overall I am extremely impressed and want to give my appreciation and admiration to those who have contributed to take the build I tried to where it is today. Please let me know what I can do to help and also if you have any ideas as to my buffering issue.

Being able to build from source is useful.
http://wiki.openelec.tv/index.php?title=...spberry_Pi

It means you can run experiments with and without new patches to narrow down where problems appeares.
Methodical testing of new builds is useful.

Being told a specific new patch makes buffering over NFS worse with H264 and DTS passthough is useful information.
Being told buffering is worse now that it was a few months back is not so helpful.

There's a post in this thread from me to Milhouse describing the numbers in the codec info overlay and how they relate to cpu based underrun, and file I/O underrun.
Would be worth reading that if you can find it.

Will do, thanks. Which base should I start building from and when? Is there anything else that I can be looking for when testing other than just my buffering issue (ie any other known issues that I can help with)?

And what is the difference between the uploaded gotham and the one with your name appended to it?

And should I be using the advanced settings file that is hosted here (http://netlir.dk/rbej/builds/) and here (https://lysin.me/rbej/)?

[popcornmix]

And what is the difference between the uploaded gotham and the one with your name appended to it?

gotham builds are based on upstream master code of xbmc (https://github.com/xbmc/xbmc).
The popcornmix build includes these patches (https://github.com/popcornmix/xbmc/commits/newclock3) which speeds up the jpeg->texture conversion.

[UteDohrs]

Great work here !!!

I just installed the "5 minute" Openelec on USB/SD (with overclock) and updates to 3.2.2

https://www.youtube.com/watch?v=E_uHc6MIpTM


How i can install your newest Gotham here by holding (not loose) the USB/Overclock combination ??

[rbej]

Updated Gotham Branch

- sync with Gotham Popcornmix branch (newclock3)

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

maybe it was already noted but I cannot shutdwon anymore, it just keeps rebooting


M

[/quote]

This is very old Xbmc bug in Gotham. Still not fixed.

[mcarni]

Thaks Rbej, I should have checked the bug report...but I was at work, in the middle of something else when i got struck by the possibility that this problem was occurring only to me...i feel somehow relieved now...


M

[allan87]

I wonder if this is the reason for theneverstill's buffering issue: "All movies ended up being in the neighborhood of 40GB".

Unless my quick math is wrong, this would require a transfer rate of about 45 Mb per second for a 2 hour movie. While that is well within the theoretical transfer rate of USB 2.0, I am pretty sure I saw benchmarks indicating actual transfer speeds (from fast USB keys) in the 20s. As I recall, the benchmarks were in the discussion about speeding up the Pi by using a USB key for the storage volume.

[allan87]

Re the shutdown bug — I have been sending a reboot command via ssh when I have this problem, assuming this is less likely to cause corruption than pulling the plug. Does that make sense. Is there a better way?

[doveman2]

Updated Gotham Branch

- sync with Gotham Popcornmix branch (newclock3)

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

Thanks, this is working nicely for me, including LiveTV.

[Milhouse]

I wonder if this is the reason for theneverstill's buffering issue: "All movies ended up being in the neighborhood of 40GB".

Unless my quick math is wrong, this would require a transfer rate of about 45 Mb per second for a 2 hour movie. While that is well within the theoretical transfer rate of USB 2.0, I am pretty sure I saw benchmarks indicating actual transfer speeds (from fast USB keys) in the 20s. As I recall, the benchmarks were in the discussion about speeding up the Pi by using a USB key for the storage volume.

You're mixing up your Mb and MB. A 40GB 2 hour movie would average 5.5MB/s, or about 55Mb/s (using 1MB=1000KB etc.). USB2 is rated at 480Mb/s, and 25MB/s read rate from USB should be possible on the Pi (with up to 12MB/s over wired ethernet). So a 40GB 2 hour movie shouldn't be a problem.

Though obviously the above is just the mathematical average bit rate, the movie could have some very high bit rate screnes which challenge a Pi, which is also why quoting the file size of the movie is pretty much irrelevant - the bitrate details from something like MediaInfo are more useful/relevant.

---

Re the shutdown bug — I have been sending a reboot command via ssh when I have this problem, assuming this is less likely to cause corruption than pulling the plug. Does that make sense. Is there a better way?

The "reboot" command would be preferable to pulling the plug, but until the bug is fixed there is no better solution.

[allan87]

Yes, I erred respecting the benchmark. The numbers were about 20 MB/s (not Mb)*. Still about 1/3 of the theoretical 480Mb/s, but ought to leave plenty of headroom for 45 Mb/s on average. (I think my math was right on the 45 Mb/s: 40,000 ÷ 120 ÷ 60 x 8, no?)

* http://openelec.tv/forum/124-raspberry-p...?start=207

[doveman2]

Unfortunately the Gotham build still has the issue where it stays on the EPG screen when changing channel and I have to press back twice to get to the picture again. This was fixed in the Frodo build I was using before.

I also have the problem where it doesn't reboot properly and just goes to a black screen but the RPi isn't shutdown as I can see the lights still flickering.

[Milhouse]

Yes, I erred respecting the benchmark. The numbers were about 20 MB/s (not Mb)*. Still about 1/3 of the theoretical 480Mb/s, but ought to leave plenty of headroom for 45 Mb/s on average. (I think my math was right on the 45 Mb/s: 40,000 ÷ 120 ÷ 60 x 8, no?)

We agree up until the "x 8" - I use x 10 when serial communication is involved... stop & start bits. Old habit. Dunno if it's more correct. But either way, ball park 5.5MB/s which is no problem for the Pi to read from USB - whether the Pi can smoothly display that amount of audio/video data is another matter.

[pennywisdom]

Possibly my own fault but when I upgraded to the new Gotham version with the features from popcornmix the GUI only ran at 720p even though my advancesettings was set at 1080p. Anyone else have this happen?

[theneverstill]

I wonder if this is the reason for theneverstill's buffering issue: "All movies ended up being in the neighborhood of 40GB".

Unless my quick math is wrong, this would require a transfer rate of about 45 Mb per second for a 2 hour movie. While that is well within the theoretical transfer rate of USB 2.0, I am pretty sure I saw benchmarks indicating actual transfer speeds (from fast USB keys) in the 20s. As I recall, the benchmarks were in the discussion about speeding up the Pi by using a USB key for the storage volume.

You're mixing up your Mb and MB. A 40GB 2 hour movie would average 5.5MB/s, or about 55Mb/s (using 1MB=1000KB etc.). USB2 is rated at 480Mb/s, and 25MB/s read rate from USB should be possible on the Pi (with up to 12MB/s over wired ethernet). So a 40GB 2 hour movie shouldn't be a problem.

Though obviously the above is just the mathematical average bit rate, the movie could have some very high bit rate screnes which challenge a Pi, which is also why quoting the file size of the movie is pretty much irrelevant - the bitrate details from something like MediaInfo are more useful/relevant.

---

Re the shutdown bug — I have been sending a reboot command via ssh when I have this problem, assuming this is less likely to cause corruption than pulling the plug. Does that make sense. Is there a better way?

The "reboot" command would be preferable to pulling the plug, but until the bug is fixed there is no better solution.

@allan87 & @MilhouseVH

Thanks for the replies and the suggestion to send media-info data. MilhouseVH was spot on - it reports the bitrate overall is 57,597 kb/s (this particular movie was 50GB). How do I tell what the bit rate is at specific scenes? Is there anything else I could check that would help?

---

Does anyone have a reply about if I should be including that advancedsettings.xml that is hosted on those two sites with the latest builds?