[noggin]

Hello,

I would like test my sd-card, but after "Write Test: dd if=/dev/zero of=/storage/test.dat bs=1M count=1024 && rm test.dat && sync" it is deleted the "test.dat,
so I can not test "Read Test: dd if=/storage/test.dat of=/dev/null bs=1M count=1024"

1024+0 records in
1024+0 records out
1073741824 bytes (1.0GB) copied, 384.643601 seconds, 2.7MB/s

/dev/mmcblk0p2:
Timing O_DIRECT disk reads: 30 MB in 3.16 seconds = 9.48 MB/sec

Doesn't

Code:

rm test.dat

delete test.dat ? If you don't include that then test.dat will be left intact?

[rbej]

Rpi 1 256mb

Without dtoverlay=sdhost reboot time 3 minutes.

With dtoverlay=sdhost normal reboot speed, but Xbmc freeze in random places.

[Calcifer-73]

Hello Milhouse,

Certainly a dumb question but why are you writing "bump to 15.0 beta2" in the changelog meanwhile on the Kodi website beta 1 was just out.

Because latest kodi commits belongs now to Beta2 -> https://github.com/xbmc/xbmc/commit/f946...f3bd2da1d7

Thanks for the quick response

[Milhouse]

Hello,

I would like test my sd-card, but after "Write Test: dd if=/dev/zero of=/storage/test.dat bs=1M count=1024 && rm test.dat && sync" it is deleted the "test.dat,
so I can not test "Read Test: dd if=/storage/test.dat of=/dev/null bs=1M count=1024"

Ah, well, yes - just don't delete it after the final (third) write test...

[popcornmix]

Actually, dmesg doesn't look at all healthy on this Pi1 when booting #0501 with the old driver - this would explain the slow booting: http://sprunge.us/SBJO (config.txt, cmdline.txt)

Is dmesg the same on Pi2? The dmesg complaints are "harmless" - they are explicit WARN() calls when an unexpected code path is encountered. It is non-fatal, but if happening regularly could harm performance. I suspect reverting this commit will avoid that (and is probably worth doing until it is resolved). I'm away this weekend so may not have a lot of time to investigate this.

[Milhouse]

Is dmesg the same on Pi2?

dmesg shows no evidence of a problem on the Pi2 when using either driver. It's only the Pi1 that has this problem with the old driver.

The dmesg complaints are "harmless" - they are explicit WARN() calls when an unexpected code path is encountered. It is non-fatal, but if happening regularly could harm performance.

Yes, there's no evidence of corruption, just a big drop in performance.

I suspect reverting this commit will avoid that (and is probably worth doing until it is resolved).

I've tested a new Pi1 build with that commit reverted (blacklisted) and normal performance is restored when using the old driver, and dmesg is now clean with zero backtraces. Re-tested the new driver on the Pi1, and that's good also.

Pi2 is good with this commit reverted (old and new driver). I'll revert the commit in future builds until you have time to investigate further. Many thanks.

[PhilE]

The message about the arm_freq parameter is referring to a DT parameter used to communicate the ARM clock speed from the firmware to the kernel. It's possible that since we are using cpufreq this setting has no effect.

I think the failure is likely to be caused by the sdhost overlay playing fast and loose by installing a global parameter from within an overlay. Once this driver is the default this won't be necessary, and there are a few other ways to achieve the same effect.

[Heiko123]

Hey, I found a great benefit about my old Raspi V1 :-)

Code:

Stop Kodi:   systemctl stop kodi
Write Test:  dd if=/dev/zero of=/storage/test.dat bs=1M count=1024  (repeated 3 times)
Read Test:   dd if=/storage/test.dat of=/dev/null bs=1M count=1024 (repeated 3 times)
hdparm Test: hdparm -t --direct /dev/mmcblk0p2 (repeated 3 times)
Delete Testfile: rm test.dat && sync (repeated 3 times)

Raspi V1 2011.12 Made in UK
Samsung Class 4 4GB MB-SS4GA

Standard driver:  Avg. Write 2.7 MB/s   Avg. Read 3.7 MB/s   Avg. hdparm 9.48 MB/s  (#core_freq=500, #force_turbo=1)
Standard driver:  Avg. Write 2.4 MB/s   Avg. Read 2.5 MB/s   Avg. hdparm 8.18 MB/s  (core_freq=500, force_turbo=1)
New SD driver:    Avg. Write 6.3 MB/s   Avg. Read 19.8 MB/s   Avg. hdparm 20.79 MB/s  (dtoverlay=sdhost, core_freq=500, force_turbo=1)

Code:

OK, here the test within #430
Standard driver:  Avg. Write 6.3 MB/s   Avg. Read 17.1 MB/s   Avg. hdparm 17.65 MB/s  (#core_freq=500, #force_turbo=1)

[Milhouse]

Wow... and does this increase in a synthetic performance test translate into a real world performance difference, ie. can you detect any improvement in Kodi performance? For example, when scrolling through the Movies library in thumbnails view - do posters appear more quickly or more often (fewer blank posters) when scrolling rapidly?

[doug]

I don't know if this is a bug or not - I can't think of a good reason why the PVR addons should be enabled by default - but without a fix coming from somewhere, my only option right now is to stop building all of the PVR addons, which I'm more than happy to do... but PVR users will be cut off.

If you can disable the PVR addons that would be great, as it will only be a problem on fresh installs, or whenever a new PVR addon is added to the build (which shouldn't be that often).

I hope you don't remove the PVR addons from the test builds. I think most of the people in this thread will figure out to disable the them. And by leaving them in we'll still be able to see how any changes to the code may impact playback performance in Live TV/PVR.

[DistantSynAck]

I did a soft reset on my RPi and noticed all the PVR clients are enabled by default.

I wonder if it's this from #0426:

• XBMC:
  • Cleanup addon (un)installing and enabling/disabling (PR:6681, 4 commits, 28 files changed)
    

Edit: Nope, booting #0425 with a fresh .kodi results in all the PVR addons being enabled too. I've gone back as far as #0315 and that has them enabled too, so this is probably a long standing issue or more likely, "by design" as, to be honest, the PVR addons are not meant to be built with the rest of OpenELEC - I only build them to a) confirm the addons actually build and b) ensure the latest addons are available with each release since the upstream downloadable addons will often be out of date (resulting in problems unrelated to the changes being tested in these builds, and we'll lose a bunch of testers as I'm not going to support those upstream PVR addons as well).

I don't know if this is a bug or not - I can't think of a good reason why the PVR addons should be enabled by default - but without a fix coming from somewhere, my only option right now is to stop building all of the PVR addons, which I'm more than happy to do... but PVR users will be cut off.

If you can disable the PVR addons that would be great, as it will only be a problem on fresh installs, or whenever a new PVR addon is added to the build (which shouldn't be that often).

Disabling the PVR addons is not a problem, as like you said it is most likely by design. It is not too often we see a new PVR and I only did a reset to troubleshoot another issue.
I appreciate you taking the effort to test as far back as #315. I was getting ready to test older builds first thing this morning but see you beat me to it. My wife thanks you for giving me more time to cut the grass.

[burr]

Most likely this is the wrong thread so feel free to point me to the correct location. I got troubles with the new FULL HD framepacking 3D over HDMI feature on my Raspberry PI 2. I tested it using those three 1 minute mkv samples from another thread here ("Gravity", "The Hobbit - Desolation of Smaug", "Thor 2") aswell as using a MakeMKV rip of "Frozen" and some HSBS samples.
With "Settings -> Acceleration -> Use Full HD HDMI modes for 3D" activated all videos play in 2D mode on my TV. If I disable it the HSBS samples trigger the 3D mode automatically and everything works as desired. The FULL HD MVC mkv files keep playing in 2D though.

So far I was just shrugging my shoulders telling myself the TV (LG 55LB650V) is crap and plainly doesn't support FULL HD 3D frame packing as HDMI input. What makes me wonder now is that playing 3D BluRays with the PS3 works. Isn't the PS3 sending the very same HDMI stream (except HDCP) to the TV when playing a 3D BluRay? I guess I'm missing some detail here that everyone else knows, just like usual ;-).

See what tv modes are supported with the tvservice command.

Here we go

Code:

OpenELEC:/opt/vc # tvservice -m CEA
Group CEA has 15 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive 3D:FP|TopBot|SbS-HH
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive 3D:FP|TopBot|SbS-HH
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive 3D:FP|TopBot|SbS-HH
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced 3D:FP|TopBot|SbS-HH
  (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive 3D:TopBot|SbS-HH
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive 3D:FP|TopBot|SbS-HH
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced 3D:FP|TopBot|SbS-HH
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced 3D:FP|TopBot|SbS-HH
  (native) mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive 3D:FP|TopBot|SbS-HH
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
OpenELEC:/opt/vc # tvservice -m DMT
Group DMT has 5 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
           mode 39: 1360x768 @ 60Hz 16:9, clock:85MHz progressive
OpenELEC:/opt/vc # tvservice -s
state 0x12001a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive

[Heiko123]

Wow... and does this increase in a synthetic performance test translate into a real world performance difference, ie. can you detect any improvement in Kodi performance? For example, when scrolling through the Movies library in thumbnails view - do posters appear more quickly or more often (fewer blank posters) when scrolling rapidly?

The sd is fast, but the system is unstable, sorry.
I'll go back the elder version.

http://pastebin.com/Xh4NmCd7
http://pastebin.com/rZdvH4hX
http://pastebin.com/j40RfvPK

[popcornmix]

The sd is fast, but the system is unstable, sorry.
I'll go back the elder version.

http://pastebin.com/Xh4NmCd7
http://pastebin.com/rZdvH4hX
http://pastebin.com/j40RfvPK

Can you check for any errors in dmesg log?

[popcornmix]

Hey, I found a great benefit about my old Raspi V1 :-)

Code:

Standard driver:  Avg. Write 2.7 MB/s   Avg. Read 3.7 MB/s   Avg. hdparm 9.48 MB/s  (#core_freq=500, #force_turbo=1)
Standard driver:  Avg. Write 2.4 MB/s   Avg. Read 2.5 MB/s   Avg. hdparm 8.18 MB/s  (core_freq=500, force_turbo=1)
New SD driver:    Avg. Write 6.3 MB/s   Avg. Read 19.8 MB/s   Avg. hdparm 20.79 MB/s  (dtoverlay=sdhost, core_freq=500, force_turbo=1)

Are the old driver numbers slower because of the warnings introduced in latest build? Does the previous build have better numbers for old driver?

In general I'd expect about 18MB/s for old driver and just over 20MB/s for the new one (for continuous read, like hdparm -t).