[Glorious1]

Recently XBMC sometimes stops while playing a video. Often this is about 2.5 minutes in, and after freezing replay for about 5-10 seconds, it exits the video and goes back to the menu. If it freezes at other times, it generally resumes after 10-20 seconds.

I have been investigating file system calls to the hard drive where XBMC accesses the media. The drive is in a directly attached USB enclosure. When I had this problem last night, I issued the command in Terminal to log files system calls to this drive. I also set up debug logging, restarted XBMC, and started the video again.

The video stopped 2.5 minutes in and exited to the menu. When I resumed I jumped past that point and the rest of the video played without interruption.

What is interesting is the file system calls from XBMC to the media folder. During the hour of running, XBMC issued about 29,500 file system calls to the TV show folder. Most of them were packed into continuous bursts of several minutes apiece. They appear to be extremely redundant, repeating the same calls over and over. At one point, there were hundreds of consecutive, identical, Rdata calls to the file I was playing. It's like an internal denial of service attack. I'm guessing the drive just gets overloaded with these calls at times and can't deal with it anymore.

I should say that this seems to be coincident with getting this new enclosure and drives. Maybe there is something with one or the other that makes XBMC repeat these calls?

Here is the debug log:
http://xbmclogs.com/show.php?id=147848

And the record of XBMC's file system calls during the hour. It is quite wide so you might want to turn off wrapping and scroll right to see the originator of the calls (XBMC). The drive itself is called XBMC.
http://xbmclogs.com/show.php?id=147978#

I don't know if this is mac-specific or not so just put it in the general help forum.

I can't make any sense of the XBMC log. I would appreciate if anyone can help figure out what is going on.

[Glorious1]

I know this is a weird, highly technical problem. Maybe I should post it in the Mac OS section?

[Memphiz]

This is out of scope of XBMC. We don't repeat filesystem calls. We just issue a open, read, seek commands to the file we are streaming whenever we need something from it. There is no way that we are repeating them. This is something which happens some layers lower (either userspace libSystem or filesystem driver in the kernel or usb driver in the kernel). Sry mate - nothing we can do for you.

Also 29500 commands in one hour is peanuts for any drive ... (do 29500 a second and we might be somewhere where the load on the drive is measurable...)

Also i have deleted your offtopic post an that other thread - don't do that please.

[Glorious1]

OK thanks, that's what I was afraid of.

Well those 29500 calls are packed into about 5-8 seconds of that hour. And these are WD Green drives, so on the slow side.

[Memphiz]

Those are 5900 iops worst - i don't think this should be a problem. But might be that the driver flushes caches at that time or something like that.

[Glorious1]

Well I have no idea, but don't forget the drive is trying to play a video at the same time, roughly 5 Megabits/sec. I think that activity is in addition to the file system calls. But maybe not.

Anyway, I'll test one of the other drives in the enclosure and see if I get similar behavior. If so, I'll see how far I can get with the enclosure manufacturer (DatOptic).

Thanks Memphiz!

[Glorious1]

In case anyone is interested, the file system was a bit fouled up on the disk. I repaired it with Disk Utility and copied the file over from the backup, then it played fine and there was a file system call from XBMC just every few seconds during play.

[Kib]

Great to see you managed to fix it.

[Glorious1]

Update: Actually, repairing the disk did not fix it permanently. Turns out the corruption was just part of the problem. The incesssant repetitive file system calls continued, and continued to be associated with stalling of videos. But now I've disabled 6 or 8 add-ons. Since then, videos have not stalled.

So I'm now hopeful that the problem was caused by one of the add-ons, perhaps in combination with some quirk of the enclosure or disks. I'd like to identify the add-on, but that would take days of turning them on and off and lengthy testing. I'm not pointing fingers, but the debug log seems to show a whole lot of activity by script.tv.show.next.aired and script.tv.tunes while the video was playing. Maybe I'll get to pinning it down someday if the fix seems permanent.

[pr0xZen]

Hoping that you'll get to re-enable these, log and see if any one of these were the cause of your issue. These kind of problems should be nipped out quite fast.