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

Also available in: Atom PDF