[J_E_F_F]

If you move the Tatu files out of the scanned directory does the stall disappear, or does it just stall at a later item?

It stalls on another directory. this time smb://FILE-SERVER/Music/diVinyls/1992 - diVinyls/

[Milhouse]

Code:

09:35:29 260.319305 T:1591735296  NOTICE: ES: Client  from 192.168.0.104 timed out

What is 192.168.0.104? The smb server or something else?

"ES" is the Event Server.

[popcornmix]

It stalls on another directory. this time smb://FILE-SERVER/Music/diVinyls/1992 - diVinyls/

Might be worth doing this a few times. Remove the directory you think is responsible and rescan.

Either you have a few files that kodi doesn't like (perhaps some embedded art or metadata, or addition files like archives),
in which case you may end up with a reduced library that doesn't stall (and we can work out what's special about the removed directories).

Or the stall isn't related to any specific file. Perhaps there is something else at play (maybe a network issue).

[J_E_F_F]

I put the T.a.t.u directory back, and it stalled at the same folder again smb://FILE-SERVER/Music/t.A.T.u/2002 - 200 kmh in the Wrong Lane

I'll remove a few and see what the results are.

All my MP3 files have embedded art, and the same tag fields (Artist, Album, Title Track, Year) (and on rare occasion 'Album Artist' if the album contains various artists) no other fields are populated anywhere. I have created all MP3 tags and embedded the album art myself. Other then the additional folder.jpg there are no other files (other then the .mp3) in any music folder. It is all very clean.

[J_E_F_F]

@ popcornmix

The stall persists.
It hung at the very end for the following directories, I removed the directory each time and then tried it again. This is the order of the hang, and each time was on the 2nd quick run through. It is normal to have 2 scans? One slow and one very fast? It seems like the first scan reads every file tag and the second scan just looks at the directory for any changes.

t.A.T.u.
diVinyls
Zero 7
------> From here they were reverse alphabetical order.
ZZ Top
Yngwie Malmsteen
Yes
Yaz

My RPi2s are connected to a gigabit network, I can sustain consistent speeds to the SMB folder much higher than the PIs are capable of.
Can't think it would matter, but the Music folder is 219GB consisting of 37318 files and is running off an NTFS formatted USB3 drive served from a WIN8.1 pro x64 computer with very little load and lots of free resources.

[polo_joe]

anything else I could try to debug my playback problem?

[J_E_F_F]

@ popcornmix

More info:

The database double scan and stall seems to only happen when I select "Update library on startup" (and then reboot)

If I manually "Scan item to library" for the entire music folder, it runs A-Z once and finishes without the long pause.

What would the difference be in how the scan is performed?

[Milhouse]

New OpenELEC Jarvis build #0910: RPi / RPi2
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 4.1.6 #1 Thu Sep 10 23:27:00 BST 2015 armv6l GNU/Linux

# vcgencmd version
Sep  9 2015 23:05:32
Copyright (c) 2012 Broadcom
version de72f07669414925f3fde745fb860bc5d4d193d8 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150910232611-#0910-g51eea0c [Build #0910]

# vcdbg log msg 2>&1 | grep DTOK
001708.699: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (51eea0c6, changelog) and tip of XBMC master (a3e75e75, changelog) with the following modifications:

• Includes newclock5 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock5
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.1.y_rebase
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest dcadec master (2a9186e3, ahead +34)
  
• Includes latest kodi-platform master (15edaf78)
  
• Includes latest libcec master (e8506b3d, ahead +29)
  
• Includes latest libnfs master (2a950065, ahead +33)
  
• Includes latest platform master (feafe68e, ahead +4)
  
• Includes latest addons: adsp.basic (da6ee5dd), adsp.biquad.filters (d940a0d1, +1), adsp.freesurround (0bc31e26, +1), asplib (ab13a4fa, +26), pvr.argustv (52a06d00), pvr.demo (039972ea), pvr.dvblink (79cc2d3c), pvr.dvbviewer (2af87049), pvr.filmon (8c444dc5), pvr.hts (d2763613), pvr.iptvsimple (14e2d589), pvr.mediaportal.tvserver (4e4b0f4e), pvr.mythtv (c94d6aa1, +47), pvr.nextpvr (c09bc2ab), pvr.njoy (91fdbd98), pvr.pctv (d00d5f8d), pvr.stalker (36fec36f), pvr.vbox (5273f25f), pvr.vdr.vnsi (73de793a), pvr.vuplus (11529b2e), pvr.wmc (2974ec38)
  
• Exclude kodi-999.99-IMX-increase-render-buffers.patch: Conflict with newclock5
  
• Exclude linux-999.20-mt7601u-support.patch: Reverted as patching order conflicts with rpi-4.1.y commits - continue using rpi-4.1.y equivalent
  
• Include e85044c6: mesa: Bump to 10.6.6 (add r8 and GR88 transfer methods)
  
• Include f2932a88: VAAPI: Bump driver and lib to 1.6.1 (enable EGL)
  
• Include 5d756bf1b7eb2ca5163aaf7034cf850b18f5ff1a...stefansaraev: Kodi 16 updates
  
• Include patch: Add rootless GPIO user access (PR1112) and RaspiDAC3 support
  
• Include patch: Add kernel SDIO support
  
• Include patch: Fix for PR:113 (libcec)
  
• Include patch: Fix x86 Get() references
  
• Include patch: Add ffmpeg dependency and includes for HEVC optimisations
  
• Include patch: Add experimental splash video
  
• Include patch: Enable pvr addons, disable PVR updates
  
• Include PR:125: Fix for holding buttons on remotes of Philips TVs (libcec)
  
• Include PR:4266: [systemd] update to systemd-224
  
• Include PR:4284: [Python] update to 2.7.10
  
• Include PR:4286: remove unused python stuff
  
• Include PR:4310: Update jsoncpp package.mk
  
• Include PR:7783: [binary addons] use TARGET_LINKER_FILE_NAME as library filename
  
• Revert PR:7885: [binary addons] fix android by using TARGET_LINKER_FILE_NAME instead of TARGET_FILE_NAME
  

Build Highlights:

1. Bump ffmpeg 2.8
   

Build Details:

1. XBMC:
   • VDPAU / VAAPI: Use HEVC_MAIN GPU decoding (ffmpeg 2.8+) (PR:7751, 4 commits, 4 files changed)
     
   • addon installer: cleanup unused parameters and code (PR:7997, 4 commits, 6 files changed)
     
   • Updated gitignore (PR:7989, 1 commit, 1 file changed)
     
   • Mrmc backports (PR:7991, 20 commits, 37 files changed)
     
   • [Confluence] Home screen: Make system.date label wider (PR:8006, 1 commit, 1 file changed)
     
   • CImageResource: adjust IsAllowed() to also accept directory paths to be able browse directories for multiimage controls (PR:8000, 1 commit, 1 file changed)
     
   • Add proper gif support (next try) (PR:7960, 5 commits, 23 files changed)
     
   • [xbmc][appmessenger] Add the ability to open dialogyesno by sending a threadmessage. (PR:7800, 2 commits, 33 files changed)
     
2. Additional commits/pull requests/changes not yet merged upstream:
   • Added: e85044c6: mesa: Bump to 10.6.6 (add r8 and GR88 transfer methods)
     
   • Added: f2932a88: VAAPI: Bump driver and lib to 1.6.1 (enable EGL)
     
   • Added: 5d756bf1b7eb2ca5163aaf7034cf850b18f5ff1a...stefansaraev: Kodi 16 updates
     
   • Added: patch: Add kernel SDIO support
     
   • Updated: patch: Add ffmpeg dependency and includes for HEVC optimisations
     

[Mfleigle]

I have a small problem that started with either build #909 or #910 (I skipped 909). When I start to play a tv show it skips the first 4~5 seconds. It mostly skips "previously on.." I have only tested MP4 files. I haven't intentionally installed anything in the past few days. Would a log file show why it's doing this?

[bagofcrap24]

Is it actually skipping or is it just reporting and incorrect time stamp.
I've noticed since switching back to OMX acceleration recently that when starting a TV episode that the osd reports at 4-5 seconds as soon as an episode starts.
Also when seeking to a chapter it seeks to the correct time stamp but the playback is about the same 4-5 seconds early.
This is most noticeable when using atv show where the chapter is the beginning of the into cinematic. With OMX acceleration when you seek to this chapter you get a few seconds of before the into.
Whereas with just mmal acceleration it seeks to the same timestamp but the playback resumes at the correct point at the beginning of the intro.
I haven't updated to the latest builds yet but I'll try tonight and see if I can reproduce.

[popcornmix]

I have a small problem that started with either build #909 or #910 (I skipped 909). When I start to play a tv show it skips the first 4~5 seconds. It mostly skips "previously on.." I have only tested MP4 files. I haven't intentionally installed anything in the past few days. Would a log file show why it's doing this?

Identifying the exact build would be helpful.
Does it occur with omxplayer enabled/disabled
Does it occur with "adjust display refresh rate" enabled/disabled
Does it occur with "sync playback to display" enabled/disabled

[popcornmix]

If I manually "Scan item to library" for the entire music folder, it runs A-Z once and finishes without the long pause.

What would the difference be in how the scan is performed?

Not something I know much about. It's not likely to be Pi specific, so a post in the OS independent forum may get a response from devs who know more about this.
Does it occur with official OE 5.95.5 build?
Does it occur with a nightly build on another platform (windows/linux)?

[popcornmix]

anything else I could try to debug my playback problem?

Can you try this test firmware.
Copy start_x.elf and fixup_x.dat and replace start.elf and fixup.dat from the boot partition of OE sdcard.

and add:

Code:

hvs_priority=0x100000

I wonder if reducing the sdram priority of the deinterlacer may help.

[zaphod24]

So I experimented more with 0910 last night. With or without deinterlacing enabled and using OMX or MMAL resulted in the same strange buffering issues playing back TV recordings using pvr.mythtv. I rolled back to 0904 and the issue went away. I also tried 0907 and it has the issue as well. Another symptom is that the CPU usage is much higher in the more recent builds, so high in fact that I double-checked to make sure that the MPEG2 hardware license was still enabled (it is). Since 0907 has the issue and the problem is with both OMX and MMAL, I am guessing maybe it is a pvr.mythtv issue? Any chance for a newer build to go back to pvr.mythtv 3.2.2?

[popcornmix]

Any chance for a newer build to go back to pvr.mythtv 3.2.2?

@Milhouse I'd be interested in the results of that. Would be good to work out if this is caused by VideoPlayer changes or mythtv changes.