OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111) +---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166) +---- Thread: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) (/showthread.php?tid=231092) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - J_E_F_F - 2015-09-10 (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/ RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Milhouse - 2015-09-10 (2015-09-10, 16:49)popcornmix Wrote: "ES" is the Event Server. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-09-10 (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). RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - J_E_F_F - 2015-09-10 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. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - J_E_F_F - 2015-09-10 @ 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. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - polo_joe - 2015-09-10 anything else I could try to debug my playback problem? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - J_E_F_F - 2015-09-10 @ 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? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Milhouse - 2015-09-11 New OpenELEC Jarvis build #0910: RPi / RPi2 (Supercedes previous build) Code: # uname -a Based on tip of OpenELEC master (51eea0c6, changelog) and tip of XBMC master (a3e75e75, changelog) with the following modifications:
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Mfleigle - 2015-09-11 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? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - bagofcrap24 - 2015-09-11 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. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-09-11 (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 RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-09-11 (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. 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)? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-09-11 (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. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - zaphod24 - 2015-09-11 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? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-09-11 (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. |