Thanks wrxtasy, your answer is very thorough as always)))
Actually I had a thought that the network part may be responsible for a shuttering due to lack of buffer space or something like this, given that my server may not feed it 100% in time due to another disk activity (torrents etc.). (I experimented with different schedulers on my home server few years ago when Dune HD, which had 100M ethernet, shows a similar behaviour. The deadline scheduler, that was the fastest back then, gave a dropout in performance every 5 min. It most probably was a sync rate: when the kernel started to sync, it interfered with NFS causing the issue. CFS, being like 5-7% slower, behaves smoothly though. Also, I got better results with NFS over UDP than over TCP. I'm not sure if it's of any value with Gigabit ethernet, that's why I asked). And yes -- no SMB allowed at my place. Only linux, only hardcore
Will try out the new release and post my impressions.
Meanwhile there are more few questions arouse.
First of all, are you planning some kind of stable releases? (UPD: I obviously can use zalaare's build. Silly me
) I'm very impressed how this tiny thing perform. However my feeling is it lucks some stability at the moment. I can use it myself without a problem, but thought about recommending it to few friends as a home solution. Having given my C1+ a thorough test I discovered it's not completely ready for a show yet. The main disadvantage is it tends to loose stability when I start to intensively jump over the file. It sustains small jumps +-10s rather well, but 10min or the next/previous chapter don't work properly -- now and then I experienced the movie was stuck until the next jump enforced, or a black/heavily corrupted screen, or even jumps to a random location. I'm afraid it's a driver issue and therefore is beyond your scope, but if not, please let me know what info may be useful to debug. (I didn't look into the logs yet to see if there are error messages there).
Second, I'm curious if any of flash-frienly file systems are available in OpenELEC kernel. The C1 doesn't have a power switch, and when powered from the TV over USB cord, switching the TV off causes C1 power loss, which is not the thing ext4 loves. Btrfs or f2fs are much more tolerant to such situations, even if we won't look at cell wearing and all this stuff, so there may be a reason to use them instead.
Thanks!
UPD: I noticed a similar behaviour on my other device (intel) with development build. I rolled back to a latest stable release (6.0.3) and found that it behaves much better when seeking to a random place. (However it fails sometimes, too (quite rarely) and I can see errors in the log). I also checked the local net speed just to be sure. It's fine. So some commits made after that version are to blame. I'll do some more research tomorrow with debug mode activated and provide the logs. Please suggest if I shall do it in this thread or somewhere else, for it doesn't seem to be odroid-specific problem. I will also check zalaare's stable build on C1 to check how it behaves.
UPD2: Having updated linux on my server it looks like the seeking problem has mysteriously gone... well, I've been jumping over the few movies severely and managed to get a black screen with only sound just once, and a couple of times -- artifacts in the upper part of screen after seeking to another chapter. Looks like it's okay now. Sorry for the false alarm.
UPD3: Tried out the new version you posted. Plays smooth, I didn't noticed that kind of shuttering I saw before. Looks like the patch is helpful
