•   
  • 1
  • 71
  • 72
  • 73(current)
  • 74
  • 75
  • 168
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
(2015-09-10, 16:49)popcornmix Wrote: 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/
(2015-09-10, 16:49)popcornmix Wrote:
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.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-09-10, 17:13)J_E_F_F Wrote: 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).
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.
@ 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.
anything else I could try to debug my playback problem?
@ 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?
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: 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:
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
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?
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.
(2015-09-11, 04:13)Mfleigle Wrote: 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
(2015-09-10, 22:03)J_E_F_F Wrote: 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)?
(2015-09-10, 20:53)polo_joe Wrote: 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.
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?
(2015-09-11, 15:17)zaphod24 Wrote: 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.
  •   
  • 1
  • 71
  • 72
  • 73(current)
  • 74
  • 75
  • 168
  •   
  Thread Closed
 
Thread Rating:
  • 10 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)510