in_zip (v0.6.8.5 29/10/2006)

[ByTor201]

Originally posted by DrO
you'll have to give me a day or so since it's taking longer to fix the issues with the new code that's gone into the plugin to handle playlist extraction and ofcourse nothing is ever guaranteed to be stable with beta supported releases (just a shame the change needed wasn't realised until a while after i'd added 5.25 support into in_zip). i will add that the dev build of in_zip that i have will work correctly with the current 5.25 beta and up now with title display but fixing some of the zip handling code issues i've got means i can't release a new build as is (since it internally has too much broken)

-daz

Completely understandable given that last minute changes are always the hardest to deal with. I can deal with the messed up title display. I'm just glad the songs still play.

[DrO]

in_zip v0.6.6.0

• Added ability to specify the main temp folder for where archives are temporarily extracted to
• Added in some info for non playing zip:// entries when viewing the alt+3 dialog
• Added in ability to extract and use the first playlist found in the archive (see prefs for options to enable this mode) but more playlist handling will come!
• Added in a workaround to allow in_zip + in_nez on a NTFS drive to work correctly irrespective of the plugin loading order
• Added in the ability to use zip:// entries in the form of zip://_archive_|_entry_ instead of the original zip://_archive_,_idx_ method (default for non-playlist entries for slight speed benefit)
• Updated to work with the finalised 5.25+ unicode interface so titles will display correctly in recent and final Winamp builds
• Improved clearing up of the temp extracted folders (especially when using rules extraction) to no longer leave files until shutdown (1.3Gb of temp data after 18hrs play is just not acceptable and if you run out of temp space it's possible to have Winamp enter a playback loop!)
• Reworked a large part of the code handling the different archive formats to hopefully be slightly faster and to remove unwanted duplicate processing
• Fixed the handling of the dsp (and newer replaygain methods) for formats like mp3 where before it would double-apply the settings (thanks to benski)
• Fixed an issue where the wrong zip:// entry was played if you'd previous tracked over a root archive entry and then tried to play the root entry again
• Everything else that was required to alter the code to work with playlists in it's current state

get v0.6.6.0

Koopa: one thing which i will make comment on before sleep, the issue koopa had with spc files, i've had someone else report the same issue and i'm wondering if it's the loading order of in_zip and in_snes that's causing the issues since that was something that came up when trying to support in_nez (needed to change it to in_znes for things to work correctly) so that may be something to have a try of renaming in_snes to in_zsnes (since i'm sure you're using a ntfs formatted drive which will allow that to work).

-daz

[Koopa]

Koopa: one thing which i will make comment on before sleep, the issue koopa had with spc files, i've had someone else report the same issue and i'm wondering if it's the loading order of in_zip and in_snes that's causing the issues since that was something that came up when trying to support in_nez (needed to change it to in_znes for things to work correctly) so that may be something to have a try of renaming in_snes to in_zsnes (since i'm sure you're using a ntfs formatted drive which will allow that to work).

Lol, right you are! I renamed in_snes to in_zsnes, now everything is fine. Thank you very much.

[ByTor201]

The plugin seems to work fine as long as I leave "Ignore all playlists and just extract all valid files." If I switch to anything else Winamp just hangs.

[DrO]

Koopatrooper: cool, right i'll have to look at adding in a specific hack or something like that so it'll work correctly with in_snes in it's normal named state (like i've had to do with in_nez).

ByTor201: can you give a link or send me a copy of the archive you're trying to play please (there's a lot of internal changes in this build though i had thought i'd caught all of the while(..) loop lockups which i guess is what's going on for you...)

-daz

[DrO]

in_zip v0.6.6.1a

• Fixed the handling of the new style zip://_archive_|_entry_ entries which could fail in certain cases (but not anymore i hope)
• Fixed the Winamp version checking to ensure the unicode features are enabled correctly for 5.25+

get v0.6.6.1a

ByTor201: i'm not too sure why but when i tried it with the archive you provided (and one i built from the files in it myself) it stripped the '3' off the found entries and so couldn't play them back since it couldn't find 'file.mp'. Hopefully this build will now work (yes famous last words yet again)

[edit]
Updated to a 'a' build due to the issue below so consider this now as what was meant to have been 0.6.6.1

-daz

[ByTor201]

Things seem to be working now, but, are those Title dialogs supposed to be there for every file?

[DrO]

doh, i've put up a 'a' build which should remove that now (link is above). and as i thought, it was a simple one line fix, doh

-daz

[Koopa]

Working perfect, just noticed that the performance with large .rar archives is a little bit better, thanks.

[DrO]

that's good news to hear i wasn't too sure if any of the optimisations would be noticeable or not since with the changes to handle playlist entries i was able to cut out a fair bit of processing whilst still maintaining compatability with the old indexing method.

-daz

[DrO]

in_zip v0.6.6.2

• Added in a workaround to allow in_zip + in_snes on a NTFS drive to work correctly irrespective of the plugin loading order (really need to work out how to easily apply this fix to all in_* that in_zip handles one day)

get v0.6.6.2

-daz

[Koopa]

I can verify that spc files in archives now work as expected when the SNESAmp plug-in has it's real name (in_snes.dll).

[DrO]

cool i also found that SNESAmp seems to fail to allow Winamp to load when DEP is enabled (which had confused me since i could never get it to work on my XP install, not helped that i'd forgotten i'd left it on for all processes when i did the great big DEP fix-up)

-daz

[Koopa]

Hehe, SNESAmp has it's perfidies, nevertheless it's the best.. er only working .spc plug-in for Winamp.

[DrO]

i think we can say that all of the game music plugins have their little 'quirks' but that sort of goes without saying especially from knowing how they're made (is generally beyond me most of the time, heh).

next main aim for in_zip is to make the playlist handling better so it'll be able to extract out playlists completely on root playback but that's for another time i think

-daz

[lexel]

I can't download the v0.6.6.2 file, but can download the v0.6.6.1a file.

[DrO]

i've no idea why that's the case (and i remember you've had issues getting other plugin builds in the past as well but i don't know what would cause it to not work). see if http://stashbox.org/uploads/11578826...p_v0_6_6_2.exe works if not then there's some sort of issue your end.

-daz

[lexel]

Originally posted by DrO
see if http://stashbox.org/uploads/11578826...p_v0_6_6_2.exe works if not then there's some sort of issue your end.

-daz

Thx, it works well.

[DrO]

k, i don't get why my direct links don't work for you, oh well at least that's a workaround again, heh

-daz

[Koopa]

Have you tried to clear your browser cache?

[DrO]

just a quick post showing something i've been working on for a little bit in my (seldom) lunch breaks at work... *click*.

the thoughts at the moment are that the [Help] button would open a separate window with what's essentially a nicer form of the the 'in_zip plugin rules file.txt' file so that it can be refered to without losing the ability to use the rules editor (which would be an integrated preference page on 5.x installs).

i've still to work things out since it's some way off at the moment but i'd possibly look at some additional features of the rules (if people need them) though i know some extra work on the '*' as a wildcard would allow me to merge most of the *sf rules into one (and i know that'd keep Mouser X happy)

-daz

[ByTor201]

Suddenly, today I no longer see ZIP, RAR, 7Z archives when selecting, "All Supported Files." I've tried almost everything I can think of to get them back - reinstalling, etc. - and all to no avail.

[DrO]

as long as the option is still enabled in in_zip's preferences under it's 'file association' section (is default off on clean installs) then it sounds like you've got too many other file types associated in winamp so that it's going over the 260 char limit for each entry in the open file dialogs (click)

-daz

[ByTor201]

Originally posted by DrO
as long as the option is still enabled in in_zip's preferences under it's 'file association' section (is default off on clean installs) then it sounds like you've got too many other file types associated in winamp so that it's going over the 260 char limit for each entry in the open file dialogs (click)

-daz

I just tried deselecting every unused filetype and it's still not working.

Edit: After doing a totally clean reinstall, things are working again. Thanks for the help.

[DrO]

heh, cool

-daz

[DrO]

in_zip v0.6.6.3

• Made an adjusment to how titles are handled so doing alt+3 on the playing extracted file should now keep the correct title and not revert back to the extracted file name

get v0.6.6.3

-daz

[DrO]

since we all like things to work faster, i've been working with the wonderful archives from http://www.hvsc.c64.org/ (since a 32k file archive is the best i can find to push in_zip to it's limits which i'm sure you'll find that it will do).

the result as of last night was a minimum of a 2 second time saving (will vary on different machines) when viewing the alt+3 dialog on the archive which was consistant over the rar,zip,ace and 7z versions of it i made/tested. 2 seconds probably doesn't sound like much but when it was taking 6 seconds to fill the list to begin with it's a nice increase (dependant on system load at the time i could nudge a 2.5 second time saving ).

i've still some more work to do to improve the handling of the extraction and title reading from such a large archive (it causes the playback of the sid files to skip when it's reading in all of the titles (with a few seconds delay at the time which isn't ideal at all).

the end result though is that for normal archives (when the work is done) there should be an improvement in overall speed of the plugin (it won't be as much as for the large archive's but there'll be some sort of increase verging on placebo levels maybe, heh )

-daz

[Koopa]

I'm glad to hear that. Thanks for doing it. Cannot wait to get a test build, heh.

If you need other big archives for testing, go to PSF Central.

[Edit]Btw, the sid archive is really extrem, 32000 files, on the Athlon I'm sitting now, the Jump to File dialog needs many seconds to pop up.

[ByTor201]

Nice to hear about the speed optimizations.

On an unrelated note, I noticed if either of the "Use playlist..." options are chosen, the tag from the file is not returned, but instead the filename within the playlist.

[gunghouk]

Hi, I've had a problem with 0.6.6.3. I have a custom ML view which shows only files ending with .zip .

When I dragged some zipfiles into this view from Explorer I couldn't queue 'em up.

Went back to 0.6.2.2 and everything worked OK again.
Weird huh ?

GH

[DrO]

Koopa: yeah, without the search optimise options enabled in jtfe it will take a while to show (though i've also found another way for when i make a new jtfe build to get a little bit more speed out of the adding in of entries into the list though it'll maybe quarter of a second max i think). the main issue for that is due to the OS control that's in use which slows down badly when you go over at 10k entries (and on slower machines is more so at lower levels).

ByTor201: that's due to the way that winamp works when you insert playlist items at a specific point (i haven't looked at altering the code to prepare a interim m3u which i insert where i need it which would expand out with the titles from the original m3u in it). i should look at doing that since it'd allow for some speed increases with larger archives on all counts i think.

gunghouk: if you can give me exact details on the view you've got setup, etc then i'll look at trying to repro it my end

-daz

[ByTor201]

Originally posted by DrO
ByTor201: that's due to the way that winamp works when you insert playlist items at a specific point (i haven't looked at altering the code to prepare a interim m3u which i insert where i need it which would expand out with the titles from the original m3u in it). i should look at doing that since it'd allow for some speed increases with larger archives on all counts i think.

Of course, if it's in the interest of speed, it seems worth pursuing.

[DrO]

aye that's true, also it'd mean i'm one step closer to getting in_zip to extract/use any playlists in the archive instead of just the first one that it finds when scanning the archive (which would be more consistant i'd think). depending on time, etc it's something that may appear sooner but we shall see

-daz

[ByTor201]

Originally posted by DrO
aye that's true, also it'd mean i'm one step closer to getting in_zip to extract/use any playlists in the archive instead of just the first one that it finds when scanning the archive (which would be more consistant i'd think). depending on time, etc it's something that may appear sooner but we shall see

That's something I'd definitely like to see.

[gunghouk]

OK I re-installed 0.6.2.3 and tried dragging zip files using Explorer into the ML view (which is just set for 'files ending with .zip'
Winamp box said 'Adding media.....' then hung with 0% added. I had to shutdown Winamp with task manager.
Hope this helps.

GH

PS. The zipfiles are karaoke mp3+g zipped files. ie. 2 files with the same name but one has a .cdg extension and the other a .mp3

[kicarus]

There's a weird issue with this plugin: When starting Winamp,with the in_zip plugin installed,the peak virtual memory/pagefile usage jumps to a dangerous level with a Windows warning to increase the VM size.I got a jump from under 170M commit to 990M just by starting Winamp with in_zip.
When I remove in_zip.dll,everything is normal.

[DrO]

kicarus: are there any zip files or zip:// entries in your playlist when this happens since the only time i've ever known the plugin use up such a large amount of memory was when i had a leak in the 7z code and was dealing with a few hundred meg 7z archive on continuous playback. if there's no entries in the playlist that the plugin supports then either there's some sort of incompatability going on with another plugin or something else with the install is going wrong. not to sure what else to suggest since it's not something i can reproduce.

gunghouk: i'll have a look at it over the weekend since the only thing i can think of which would cause that might be the extended meta data functions but we shall see what i can find.

-----------------------------------------------------------

the speed optimisations are taking a bit longer to work on at the moment since i've found (well on the test setups i can make) that with all of the 5.2x series of Winamp, there's a slowdown/bug in the api used to insert a playlist entry at a specific by plugins which means for the hsvc archives i'm looking at about 10minutes to have it extracted out into the playlist compared to the 20-25seconds on the 5.25 beta installs. due to this i'm going to have to push the temporary m3u generation code through sooner (both for the speed advantage i mentioned earlier but also one api call and then getting winamp to expand out the m3u should be faster on 5.2x installs as well as all other installs but we shall see when i implement it). so for a change it's not my fault it seems, heh

-daz

[DrO]

the speed optimisations do work with the pre-generated playlist and i can get the titles from the playlists being extracted used (so that it matches up and seems to be transparent). the issue now is that the api which was causing the massive slow downs on the 5.2x builds (still not sure on why that is) has another issue... the effect is that you can use it to insert a file/playlist into the playlist editor at a given point _but_ only the first playlist entry will remain at the location with all other ones enqueued onto the end of the current playlist (which obviously isn't what i'd expect). so will need to try and see if this can be fixed for the next winamp release.

so until then i'm going to hold out on a new in_zip release (though i've also fixed a few other random issues and got some better speed response with the hvsc archives) since i'd prefer to know what version of winamp i can rely on to work properly first before switching the code over porperly to the playlist insertion method (plus i don't want to release a build that's then got to be changed later on for winamp version compatability which is all i seem to do of late, heh)

-daz

[DrO]

well 5.3 is out now (tfft) and the api change needed was implemented so i'll look to trying to fix things my end as soon as possible so that we can have a faster in_zip build with 5.3+ installs

-daz

[Koopa]

DrO, is there a hack possible, which always shows "Archives (*.ZIP,*.RAR,*.7z,...) in Winamp's open file dialog without the need to check "Allow archive files to be associated with Winamp" in in_zip's configuration?

Problem is, I like this entry, but I also like to click on the "All" button in preferences -> files types, but I won't register archives with Winamp.

Or is there a technical limit?