[Jönke]

Did a quick test and i got live tv running on that build but cpu use was near 100% all the time both on sd and hdtv 1080i.

[FattyMcDirty]

so.. which is actually the most stable and reliable build at the moment? (which is also fluid in gui..?)

[Koloss]

All people says every USB-Stick is faster as a sd-karte:

My test, Pi boot time, same latest rbej image:

SD-Card, Sony SF16UX Class10 16GB SDHC :
28 seconds

USB-Stick, Lexar® Echo ZX Backup Drive 8GB:
45 seconds

[Milhouse]

Filesystems mounted from /dev/* or with LABEL=*/UUID=* will be automatically fsck'ed before being mounted.

If you're using a large-ish USB, it will take a noticeable amount of time to be fsck'ed, and increase the time to boot the system. My 32GB USB3.0 memory stick takes a good 25 seconds to be fsck'ed. Not sure why your SD card should be so much quicker to fsck, perhaps you only had a small partition on it and not the full 16GB?

Obviously, booting over NFS (or SMB) there's no delay due to fsck. Must admit I'm not seeing a huge win with USB compared to NFS, despite this particular USB being good for 25MB/s read and 13MB/s write rate - I think the 1080 fanartres and 720 imageres nullifies any benefit from improved IO.

[Koloss]

I have to 2 same SD-Cards

First Config, Only SD-Card::
My SD-Card:
125MB Fat
14.9GB Ext4


Second Config: SD-Card and USB-Stick:
125MB FAT A-Card
USB-Stick 8GB Full Ext4

I use this mount with USB-stick:
boot=/dev/mmcblk0p1 disk=/dev/sda1 ssh quiet

[trogggy]

All people says every USB-Stick is faster as a sd-karte:

My test, Pi boot time, same latest rbej image:

SD-Card, Sony SF16UX Class10 16GB SDHC :
28 seconds

USB-Stick, Lexar® Echo ZX Backup Drive 8GB:
45 seconds

Boot speed is fairly irrelevant on a pi if you leave it on all the time. I've never measured, but I've used class 4 and class 10 sd cards, usb2 and usb3 sticks. My impression is that my usb3 sticks (transcend 8GB) are a lot quicker with menus / loading images than my class 10 sd card (sandisk 16GB). USB2 sticks (and I've tried a few) don't seem particularly quick.

[theneverstill]

"Indeed this is one of the drawbacks of handbrake / H.264 and trying to achieve the same quality as the original bluray"- why reencode it, then?

Funny, at RF 20, I can't tell the difference between an HD original (recoded OTA), unless I freeze frames, go right up to the TV and look closely.

If you like RF 20 then go for it. I'm glad that works for you.

If you can point me to a guide to getting my RPi to consistently/stably play raw bluray isos then I will have no reason to encode. Until then, it is because most distros can handle H.264.

[Koloss]

I order a new transcend in the next week USB 3.0 Transcend 780 8GB Stick

Tested with 30sec scroll fanart
My next test with 30sec(Automatic stop in 30 sec) scroll fanart USB-Stick vs. SD-Card:
The USB-Stick stops later in the movie list, he is FASTER.


My next test with usb-stick:

I add this and reload my textures:
<fanartres>720</fanartres>
<imageres>512</imageres>

All fanarts 512px and all fanarts are 720px, its ok!

Tested with 30sec scroll fanart movies(Automatic stop in 30 sec), the result i stop in the same Movie with old and new settings!
I cannot see a performance different to my old settings:

This tweak has no effect! Sorry, @popcornmix.


Next problem, i cannot install amber skin in this build, it is incompatible. Now i cannot see the skin do install it

[hpbaxxter]

If you can point me to a guide to getting my RPi to consistently/stably play raw bluray isos then I will have no reason to encode. Until then, it is because most distros can handle H.264.

You could just take the main m2ts stream of the bluray, for example, then only chapters are missing. It's usually around 33 GB and should play well on an overclocked rpi. Except for dolby truehd audio streams, but you can chose another audio stream. H.264 and VC-1 work, provided you have the licence.

[Koloss]

Dolby true hd is now passthrought now runnind or downsampling do DD?

[doveman2]

You could always put location / timezone info in an advancedsettings.xml. Saves setting up, and unless your pi is a regular traveller...

I actually found a while back that I need to edit advancedsettings.xml and guisettings.xml with the correct Locale information for the correct time to show. So this was already done but I still had to reboot again after updating before the correct time would show.

---

Updated Gotham Branch

- sync with Gotham Popcornmix branch (newclock3)

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

http://lysin.me/rbej

Thanks, two minor issues:
1. Shutdown doesn't work (keeps rebooting)
2. SD LiveTV channels (MPG2=enabled) start fine and then stop after 2 seconds

That's strange as SD LiveTV (Freeview, TVHeadend, TVH and USB tuner both on the RPi) works fine for me. I just can't skip through recordings.

I don't think I've tested Shutdown but reboot doesn't work for me and just dumps me to a blank screen.

[Cassiel]

You could always put location / timezone info in an advancedsettings.xml. Saves setting up, and unless your pi is a regular traveller...

I actually found a while back that I need to edit advancedsettings.xml and guisettings.xml with the correct Locale information for the correct time to show. So this was already done but I still had to reboot again after updating before the correct time would show.

---

Updated Gotham Branch

- sync with Gotham Popcornmix branch (newclock3)

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

http://lysin.me/rbej

Thanks, two minor issues:
1. Shutdown doesn't work (keeps rebooting)
2. SD LiveTV channels (MPG2=enabled) start fine and then stop after 2 seconds

That's strange as SD LiveTV (Freeview, TVHeadend, TVH and USB tuner both on the RPi) works fine for me. I just can't skip through recordings.

I don't think I've tested Shutdown but reboot doesn't work for me and just dumps me to a blank screen.

Currently using TVHeadend on my NAS and H.264 Channels do work… I first thought it was a bandwidth problem of the USB WiFi adapter, but HD channels work great. Maybe deinterlacing is breaking the SD playback?

[theneverstill]

If you can point me to a guide to getting my RPi to consistently/stably play raw bluray isos then I will have no reason to encode. Until then, it is because most distros can handle H.264.

You could just take the main m2ts stream of the bluray, for example, then only chapters are missing. It's usually around 33 GB and should play well on an overclocked rpi. Except for dolby truehd audio streams, but you can chose another audio stream. H.264 and VC-1 work, provided you have the licence.

Genius! I'll use tsmuxer to rip the main mpls (thankyou BDInfo) which will combine all of the necessary m2ts files in the right order, then use mkvmerge to throw the audio (using eac3to to give me the best hd pcm and also a downmixed stereo - converted from best audio on disk), chapters, and potential forced subs back in! Giving that a try now...

[theneverstill]

@hpbaxxter

Thankyou! That worked wonderfully! Not only are my rip times cut TREMENDOUSLY but it appears as if the original video plays MUCH better than the encoded versions. My original test was with Iron Man 1 and this one was with Star Trek 2 (the new one).. so I know it isn't exactly an apples to apples comparison -- which is why I'm redoing iron man 1 as we speak.

However, that being said, if you read my previous posts I was using 100% CPU and the buffer kept getting emptied out. Now, I am still using the 7.1 PCM audio, and still playing a 1080p movie, but here is the comparison:

Different: Movie and therefore bitrates (Iron Man 1 vs Star Trek 2), resolution (1920x1088 vs 1920x1080), and filesize (50GB vs 35GB)
Same: Both BDs, 7.1 PCM audio, standard clock rates (no overclock)

Result: Star Trek 2 plays wonderfully and only uses ~70-75% CPU

---

I'll post again when Iron Man 1 has been reripped and remuxed.

[hpbaxxter]

Glad that I could help, and thanks alan87 for the hint. Seems like exceptionally high bitrate is a problem and pcm just works fine, as filesize perfectly correlates to cpu usage ... as both films are 2h + a little, I presume that average bitrate and filesize correlate as well. Hopefully we are right and Iron Man will show better playback as well!