Going up a directory takes long

[Borgland]

Hi
I have noticed that when I go up a folder that’s shared with SMB, the whole directory is repopulated. There are more than 100 files and folders, so this repopulate action takes about 3 seconds, and this is quite frustrating, as I just want to go from the “Series A” folder to the “Series B” folder.

Can’t the directory listing that WiiMC was at last time be saved somehow?

This is the first time that I am taking a look at WiiMC’s code, so I have a few questions:
I see in the function BrowserChangeFolder() calls ResetBrowser() every time. Does this discard all the previous directory/file entries? I suspect so since it resets numEntries to zero

browser.numEntries = 0;

Does this also effect the browserList static list variable? I can’t find anything, if it does.

BrowserChangeFolder also calls ParseDirectory which calls ParseDirEntries, which adds entries to the browserList. If I change BrowserChangeFolder to not call ParseDirectry every time, it might solve the problem. Perhaps if its changed to only call ParseDirectry it on entering a directory, and not when the user browses to the “..” directory?

Anyone with some tips?

I am about to setup my dev environment as per the instuctions. Will let you guys know what I’ve discovered.

Thanks

[rodries]

3 seconds is “quite frustrating”? You have a low tolerance!

What you’re asking for would require a great deal of optimization.

Consider that right now WiiMC sets aside 2000 directory entries for one directory path. Each entry requires approx 1534 bytes. So 2000 x 1534 = approx 3MB. That’s for one directory. If you’re considering caching additional directories, the storage requirements would grow quickly. Consider that although the Wii has a total of 88MB of RAM, a huge amount of that is sucked up by other things. You really don’t have that much to play with.

So in order to do what you’re suggesting, you would have to
-only allocate as much as required for each entry
-track memory closely to ensure all of it is freed when no longer needed and can be reused
-track total memory footprint and expand / shrink as needed (?)
-determine a logical caching scheme
-etc

You would also have to consider that directories can be moved/renamed/contents changed

[cadbusca]

It takes about 1 second for every 100 entries.

More frustrating is the apparent hang when the directory has lots of entries that do not show in the current mode….
so my camera directory with 500 entries, is mostly jpgs with a few mpgs. When I open it in picture mode I get a loading message (after the first 20 jpgs are parsed) and wait 5 seconds for the listing. When I open it in video mode to get the mpgs, no wait message appears and I have to wait 5 seconds thinking it hung up until my 13 mpgs list.

If the only purpose of the 20 parse logic is to hold the wait message until 20 have been parsed, it fails to work in this instance.

[Borgland]

After reading through some of the code I want to make a suggestion. The browserList and browser global variables are used in quite a few places in more or less the same way. I want to encapsulate this in a class. The interface that I thought of so far could be something like this:

class Browser

{

public:

static BROWSERENTRY&  getBrowserEntryAtIndex(int index);

static BROWSERENTRY&  getSelectedBrowserEntry();

static void addBrowserEntry(const BROWSERENTRY& entry);

static std::string getLastDirectory();

static std::string getCurrentDirectory();

static void setSelectedIndex(int index);

static int getNumberOfEntries();

/* TODO more things here */

};

This of course does not include all the members of the BROWSERINFO browser struct yet. My idea is that this class will completely take over the way the browserList and browser structs are currently used.

Eventually this class could also contain a list of directory entry lists, so that we can hold more than one level of directory entries at a time. (I thought that WiiMC could only re-parse a folder once it enters it, instead of on every directory change.)

I want to hear what you guys have to say about this suggestion before I submit a patch.

Tantric: you said that “WiiMC sets aside 2000 directory entries for one directory path”. That’s true, but only for directories with 2000 entries. Directories with less entries will luckily use less memory. (See AddBrowserEntry() in filebrowser.cpp )

jhb50: I haven’t taken a good look at the picture mode code, but I guess to solve your problem, would be to filter the directories earlier, for different modes. Does WiiMC know what extensions it supports for a given mode?

[rodries]

Tantric: you said that “WiiMC sets aside 2000 directory entries for one directory path”. That’s true, but only for directories with 2000 entries. Directories with less entries will luckily use less memory. (See AddBrowserEntry() in filebrowser.cpp )

See wiimc.cpp:

browserList = (BROWSERENTRY *)mem2_malloc(sizeof(BROWSERENTRY)*MAX_BROWSER_SIZE, VIDEO_AREA);

Doesn’t matter if it has less than 2000, at the moment this is the memory allocated in the MEM2 area called VIDEO_AREA.

Re: your browser class idea – why do this is C++ rather than C? You can just as easily use structs, malloc, etc. I’m not completely opposed to C++, but also realize that it is going to use more memory up to use classes – C++ increases the footprint.

[Borgland]

See wiimc.cpp:
browserList = (BROWSERENTRY *)mem2_malloc(sizeof(BROWSERENTRY)*MAX_BROWSER_SIZE, VIDEO_AREA);
Doesn’t matter if it has less than 2000, at the moment this is the memory allocated in the MEM2 area called VIDEO_AREA.

Ok, I missed that one, you are right.

You can just as easily use structs, malloc, etc. I’m not completely opposed to C++, but also realize that it is going to use more memory up to use classes – C++ increases the footprint.

I want to use a class to encapsulate the browser list idea. One advantage is that it hides the details of the relationship between the browser struct and browserList list. If a programmer has to call AddBrowserEntry() every time he/she wants to add a new entry to the browser AND remember to call browser.numEntries++; eventually someone will forget, and cause a bug.

How about, we start addressing the larger memory issues first. Can I change browserList to be of type std::vector so that the initialization of all 2000 entries isn’t done upfront?

[Borgland]

Added a task with a patch to change the browserList to std::vector. Any feedback would be appreciated.

When merging I saw an mplayer file (subs/subreader.b including filebrowser.h) including a WiiMC file. This dependency seemed strange to me. Shouldn’t it be the other way around? Either way, I fixed it by adding a new define.

[Author]

Posts