[rodries]

Right now it’s set to 5 minutes.

I’ve added the ability to change that for the next version for you. 🙂

Note that it can’t be set below 1 minute.

[rodries]

My suggestion is to re-read what rodries wrote. He already answered this:

di_* changes will allow to play a video dvd, using dvdnav and dvd://

[rodries]

You’re still missing libexif.

[rodries]

@Ataraxis, no he’s missing ALL of the libs. So he didn’t follow the instructions at all 😯

[rodries]

You could be getting wireless interference. You could try changing to a different wifi channel. Or a more permanent solution would be to get a USB ethernet adapter.

[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.

[rodries]

Sure, if you don’t mind waiting for the buffer to completely fill. This cache % setting is actually what % is filled before playback begins. If possible the buffer will fill itself completely while the video is playing, regardless of what % you set. Same goes if you pause the video for example – the buffer will be filling and will fill to the full 8MB even if you set 10%.

[rodries]

No. Maximum 8MB, like I said above.

[rodries]

It’s 30% of the allotted cache, which is 8MB.

88MB is the total memory – that includes WiiMC itself and all of the memory it needs.

[rodries]

The compilation instructions are updated upon release of a new version – and not necessarily during development of the release.

[rodries]

Sure. It’s not compatible. You can hope someone alters the code to make it compatible (if it’s even possible) but I wouldn’t hold your breath…

[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

[rodries]

I think he’s right! That was test 4.

[rodries]

I would be concerned too, since method 5 is the one we’re going with.

[rodries]

Try removing the no_ios_reload line from meta.xml and report back.

[Author]

Posts