Project

General

Profile

Actions

Bug #10

open

XBMC has atrocious I/O pattern when connecting to a CIFS share of music

Added by bombbloke almost 14 years ago. Updated over 13 years ago.

Status:
New
Priority:
Normal
Assignee:
somebody
Category:
Streaming (Local)
Target version:
Start date:
Due date:
% Done:

0%

Resolution:
Affected Version:

Description

_BB's notes:

Initially submitted here by TheEvilHammer. Suspect this applies to all platforms, but it seems no further testing has been done._

====

I recently configured my XBMC to connect to a shared folder on my Windows laptop that has my music. I noticed that it was taking a really long time just to connect to the share over the network, so I fired up Wireshark on my laptop and took a network trace. Here's what happens:

1. TCP connection
2. SMB/CIFS connection
3. SMB/CIFS Authentication
4. Tree connect
5. FIND_FIRST2

At this point, everything in the top level of my shared folder is returned, which includes a couple directories and half a dozen playlist (M3U) files. At this point, XBMC opens each playlist file in turn and parses the entire file. I think this is a bug already, as there's no reason I can think of that XBMC should be doing this. The playlist file should show up in the list of files and that's it - no parsing should be done. Only if the playlist is opened or played should it be opened and parsed.

Anyway, let's assume for a moment that this is actually the desired behavior. What follows is nothing short of horrible:

Read AndX Request, FID: 0x4000, 1023 bytes at offset 0
Read AndX Response, FID: 0x4000, 1023 bytes
Read AndX Request, FID: 0x4000, 1023 bytes at offset 9
Read AndX Response, FID: 0x4000, 1023 bytes
Read AndX Request, FID: 0x4000, 1023 bytes at offset 61
Read AndX Response, FID: 0x4000, 1023 bytes
Read AndX Request, FID: 0x4000, 1023 bytes at offset 113
Read AndX Response, FID: 0x4000, 1023 bytes
Read AndX Request, FID: 0x4000, 1023 bytes at offset 159
Read AndX Response, FID: 0x4000, 1023 bytes

Yes, XBMC is reading 1 kB at a time, and using only 40-50 bytes or so. This continues for the entire playlist file. Those offsets correspond to the start of new lines in the file, so the actual amount of data transferred across the network is:

(number of lines in file) x (1 kB)

Simply connecting to my CIFS share and listing the 8 or 9 files/folders in there caused over 2 MB of data to be transferred over the network. Needless to say, this is really bad.

Actions #1

Updated by arnova almost 14 years ago

This is actually quite interesting and could partially explain the bad performance of Samba in XBMC...

Actions #2

Updated by arnova almost 14 years ago

Please also submit this bug on xbmc.org since mainline has the same issue.

Actions #3

Updated by arnova almost 14 years ago

Can you give r30443 a try?

Actions #4

Updated by bombbloke almost 14 years ago

I'd probably need to setup this "WireShark" thingy to get any real results back. I've posted a note to Hammer on the original ticket, though if he doesn't get to it soon I'll take a stab at it myself.

#33 appears related to this.

Actions #5

Updated by bombbloke over 13 years ago

I did some tests, still works the same way. The redundant reads are triggered by the playlist-parsing code, and since the file doesn't get cached locally, the network gets used over and over again.

(Parsers grab a 1kb chunk for every line they wish to read from the file. Average line length is probably around <80b, at least in my playlists.)

Best fix would probably be to re-write the playlist parsers to only read what they need to.

Actions #6

Updated by arnova over 13 years ago

Yeah, to be more precise: The playlist readers should just read the whole file into a CStdString and parse it then line-by-line...

Actions #8

Updated by buzz over 13 years ago

have the changes in 30738 improved things at all ?

Actions

Also available in: Atom PDF