Jump To File Extra (JTFE) Discussion / Bugs / Updates (1.33 Build 1216 - 16/12/2013)

[DrO]

fixed it all now for the next dev build release. problem was related to the rebuild of the code and not all of it was using the 'on end of queue' message handlers. that's now fixed and there shouldn't be any issues with it. new release should be in a day or two (real life permitting)

you can set the on end of queue via right clicking the stop button in the main player window, via the right click menu on the jump to file dialog and then from any of the manage enqueue list views be that the one you were using from the preferences or in the media library queue list view.

-daz

[dazbradbury]

Wicked, thankyou very much.

Oh, and any update on the picking a member of the queue problem, whereby if you have two entries, it picks the one higher up...? (Can be overridden with alt-click, but would be nice to have in general...)

Thanks so so much! Cheers. Daz.

[DrO]

Originally posted by Michgelsen
The ability to use the playlist font is great! Thanks for that.
However, the line to the right and below the list in the jump to file window would look better if it totally surrounded the list, instead of surrounding only the right and lower side.
Although the current type of line looks fine in the media library, in the jump to file window the totally surrounding line would look a lot better in my eyes.

I hope you can make that.

Thanks in advance!

have a look at the attached screenie you'll need to add wadlg_jtfefunky=1 into the [jump to file extra] section in your winamp.ini and the next time winamp's run then the plugin will draw the left and top edge for the list and edit boxes on the jump to file dialog (is too much of a pain at the moment to make it only work on the list and for a consistant look it's better to be applied on all controls as needed i think)

dazbradbury: i'm still looking into how i can change the current code to handle that correctly since as soon as you make changes to the playlist then it'll revert back to the first instance of the track found (this is a throw back to how the original versions of the plugin handled playlist changes and i'm still not sure on how best to try and work around this). so i can't say when since i don't even know if i can reliably fix it and since it's been in it for however many years now i think it's just one of the plugin's known quirks, heh

-daz

Wow that looks perfect, exactly what I meant! Thank you very much!

[DrO]

0.97.5 (Build 28) is out:: release info

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

This currently leaves it with known bugs being the shell enqueue feature and the media library favourite views sharing the same column widths instead of using their own widths. And yes language support to be re-added blah blah blah

-daz

[TazDevil]

2 issues.

toggle jtfe window when hotkey is pressed twice, only works when the jtfe window does not have focus. (for me Winkey+J) should shade jtfe window on/off where-ever the focus is, instead of typing jjj's in the text box.)

Enable windowshade mode for classic skin fram windows option in preferences has no effect. (is it implemented yet)

[DJ Egg]

'Enable windowshade mode for classic skin gen frames' (Prefs > Jump to File > Misc) works fine for me. When you checkmark/uncheck it then switch to any other prefs page (or close prefs) you should see a messagebox popup prompting that you need to restart winamp for the change to take effect.

[Logy]

dro in my case, did you inspect what make jtfe react like that, it is known bugs?

[TazDevil]

Oh ok DJ Egg you are right but,

not that i mind (because i like it on) but off works for all windows except DL. i was testing with DL window so i wouldnt know.

Anyway it could be DL issue or some customisation in jtfe for DL. in any case if it is in DL it will be fixed in the next rewrite otherwise if it is in jtfe that means code reduction.

[DrO]

Logy: i've not had a chance to look into the issue though to be honest, there has always been a slight delay in the display of the jump to file dialog be it in a skinned or un-skinned mode

TazDevil: is it just the DL window that's having issues? i know the jtf window will still keep the windowshade button even when the mode is disabled (since that's how it was working at the time). if it is just DL that's the issue then can you send me a copy of the dll that you're using since i've completely lost track of which was the last public build of 2.0 beta (though i'm fully aware of the rebuild of the plugin, i'd like more out of curiosity to see if it is something my end or not though i remember DL doing funny things beforehand which caused issues that weren't jtfe's fault)

-daz

[DrO]

just had TazDevil on irc and have resolved the issue of the winshade feature not correctly turning itself on/off (was only partially obeying the option in the preferences).

also adjusted the point at which the winshade mode is applied which fixed my issue of the DL plugin never getting the winshade state and TazDevil's issue of the ML not having it correctly applied. is now working correctly either way (damn you different plugin loading orders!!)

-daz

[Logy]

hi dro, you're right! nothing you can do agains that case, because it is OS false, when i try press j on winamp, it is seems ok with win me, or may be win 98 (i'm not tested yet) ... but not with win xp.... ! any way, forget this case if it is very annoying (waste time) you!

adios!

[spin26]

on the colorize option... you can colorize text if highlighting is enabled... i wish i can colorize text only without highlighting the background... thanks

[DrO]

i've still to look at the issues you'd reported with the colouriser and was going to look at any modifications that could be done at the time for just doing the text though you should be able to select the same colour as the current skin's colouring to achieve it easily

-daz

[mattmeow]

Found this problem on new install's of winamp on 2 different computers. (sorry if this has been reported already.)

Problem is with "Remove Duplicate Entries" thing in the playlist editor. Deletes all instances of a song, instead of just one or more duplicates when there are more than 2 instances of any song.

This is the easiest way to reproduce the problem is to add the same playlist into the editor multiple times (4 or 5), then sort by title, then remove duplicate entries. When this is done all the entries are removed (only one or two songs may be left out of a a few hundred non duplicates.)

[DrO]

and there's also this which is the same and i can reproduce it though i don't know why the code is no longer working correctly now. i'll be looking into it for the next build of the plugin

-daz

[upsfeup]

A suggestion.

I was browsing my old posts on winamp forums and found this request: http://forums.winamp.com/showthread.php?threadid=238215

Originally posted by upsfeup
I've been searching for a plugin to do this but so far.. no good! But I guess it is good enougth for winamp core!

What I want is an option thats turns on Shuffle/Random mode at the end of the play of the last entry of the playlist.

Has anyone found this?

Since JTFE adds an "On end of queue" button, is it possible to add this option? I need non stop music

[BugMaster]

I understand that making patches for elseone's programs is making EVIL but I can't wait anymore for the next release that will fix this bug. So I hope DrO will understand me (Please do not anger). My patch fix the bug described here.

[mattmeow]

patch works great, thanks bugmaster

[DrO]

BugMaster: what it was that you patched would be good to know since i'm ok with patching as long as i know what it is that is being done

-daz

[BugMaster]

Originally posted by DrO
BugMaster: what it was that you patched would be good to know since i'm ok with patching as long as i know what it is that is being done

-daz

As I understand your algorithm it works like this:
1) making hash of all tracks in playlist
2) making loop(cycle) for tracks from 1 to n-1 (variable i)
2.1) making for tracks from i+1 to n (variable j)
2.1.1) comparing hash[i] and hash[j]. if they equal than add track j to special removal list.

Example: if the playlist is "A,B,A,B,A,C,D" then algorithm will generate such removal list "3,5,4,5". The problem is that list contains track 5 twice and as I propose in such situation Winamp will also remove track 6. The result playlist will be "A,B,D".

And I only change step 2.1.1 by adding the check that track j is not already in the removal list. For above example the removal list will be "3,5,4" and the result playlist "A,B,C,D".

But now I test the above example and found that my patch also work incorrect. Results:
original - "A,B,C"
patched - "A,B,A,D"
I think the problem is that that removal list must be sorted.

Now I think that more correct(speed/performance) will be to delete duplicate entries during the sorting.

Would be glad if you make such patch (next release) as soon as possible.

Sorry for my bad English. I hope you understand what I wrote.

[DrO]

yeah, you're assumptions are correct and is why i'd started to re-code the removal list before i went on holiday but ran out of time to finish things so i could properly test it.

removal as i find them is an option but generally proved to be a lot slower and is also why i remove the entries in reverse order since Winamp is able to cope better with removing from the end of the playlist over from the start of the playlist due to display redrawing, etc (well that's how it worked on my old P2 box when i first created the feature and i'm sure it would still be same from what i remember from another one of my plugins).

as soon as time permits then i'll get things sorted out but i've got a load of other things to sort out non-dev related after my week away.

-daz

[BugMaster]

For people how can't wait (like me) I make the second version of my patch which fix the bug of first version. I only add sort after all.

DrO: If you will try to delete duplicate entries during the sorting I recommend to test it on such playlist "A,A,A,A,A,B,B". Because there is problem that removal list is too small (n+1 entries) and the algorithm stop to add duplicate entries in it. As result I get "A,B,B".

[DrO]

second time to make this post since the forums borked on me last night as i was going to post my results.

i had a quick look at the code again trying to see if i can fix the existing code or if it is going to be easier to re-code the whole thing. i noticed when i'm in the inner 'j' loop once i've found a duplicate it would keep going which didn't seem right, so i added in a break statement once i've added the index into the buffer.

trying things with that gave me correct results for the first bug report and also for A,A,A,A,A,B,B test in your post above. i'm going to have to do some more testing but i think that's it though (which makes things easier for me). alas other parts of the plugin are broken which makes putting out a new build on my part tricky since it would cause more issues than good at the moment. so if you want to try and patch in a break statement after the index is added into the memory buffer then go for it and see if it works (it hopefully should) and that should keep things happy for the time until i release 0.97.6

-daz

[BugMaster]

DrO: You are right this method is more effective (quicker) than searching the existence of item in removal list. But the final sorting is also needed. For example: the result for playlist "A,B,B,A,C" without sorting will be "A,B,A"

New version of patch that makes break and final sorting (must be quicker than previous one)

[Red Mullet]

Works well thanks for put my thread:http://forums.winamp.com/showthread....hreadid=251229 in new thread.

[spin26]

shell integration is broken but some parts work...
maybe a new GUI might make it work and easier to understand.. i have also included colorizer option in my suggestion


under the highlighting options..
i think the "colorize text of queued items" should be enabled without having to enable "highlight time text entry BG." because as of now i use to choose same background as the playlist background but when the queued item is selected.. it blends with the background... <dark blue under the default classic skin>
what i want is red text for missing files and yellow for queued ones.. without the background highlight...

[DrO]

BugMaster: is all natively done now with sorting on the generated duplicates list so if you wouldn't mind confirming it's fix in the next build of the plugin that would be appreciated. i've tested it on all of the example cases that i've seen posted and it's working correctly with all of them so fingers crossed it should be all resolved now

spin26: the colouring feature is currently limited to just the time part as in the older versions and unless a decent winamp.exe fix can be implemented that's how it's going to remain so i'm not going to look at any colouriser related issues until/if i can get things working with 5.25 again (win9x unicode support is what's killed how jtfe hooked into the playlist drawing)

-daz

[DrO]

quick update, the highlighting of queued entries, etc is now fixed for the next build. also it's now possible just to set the text colour of the title column instead of having to have the spam background colour option enabled - with the fixes done i worked out how to get this implemented along with massively optimising/improving the code (so it shouldn't really cause any incorrect flashing as it could do before i think/hope).

language support is ~70% done with most of the preferences translatable now (along with a number of speed/memory optimisations for the language file handling code).

i've also optimised/improved almost all of the code that i can do which has also helped to drop the dll size by at least 8kb (not bad i think ). i'm not sure when the new build will ship since i need to finish the language file support and a few other minor changes but it should be within the next few days so i can then get back onto another project again (needed to push a new jtfe through due to the changes with 5.25 so i can leave the project alone for a while again).

-daz

[Pade2204]

Jump to file v. 0.95.5 with Winamp 5.24

I have noticed a annoying problem.

When editting the "Display" tap in winamps 'Jump to file' options;

"Use text formatting in the playlist"

When I use the %st function (a VERY useful function) it makes some strange queues.

I have used different strings, like: [%N]%st

THE PROBLEM:

when having the above string (or any other with %st) and I press the "q" buttom in the playlist to queue, it sometimes shuffles away from the wanted song, and puts another song in queue. 1 out of 2 times it works ok. But its pretty annoying.

My other settings in winamp:

I use overall shuffle and repeat. I also have plugin 'iZotope Ozone' installed.

Thanks for the "jump to file" work. Its amazing!

Can anyone help me ?

Regards

[BugMaster]

Current version is v0.97.5 (build 28), but I think you mean it.

I try to reproduce this bug, but I can't (even download 'iZotope Ozone' for testing). May be it is some specific settings? It would be good if you send (attach) your zip-ed 'winamp.ini' for testing.

P.S. Did you try to make clean reinstall of Winamp?

[Pade2204]

Bugmaster, I must say a reinstall of Winamp helped, BUT...

the %st function seems to calculate wrongly.

If you queue 1 file it calculates the time for playing the next song correctly. But if you add more songs, like 3-4, then it's easy to see that it calculates the songs wrongly. You can also see it if you let winamp play through the queued songs the %st function does all the corecting when time comes...

Thats something that make the function useless

Can you see what I mean - and thanks for trying figure out my problem

Regards

[BugMaster]

Originally posted by Pade2204
You can also see it if you let winamp play through the queued songs the %st function does all the corecting when time comes...

Dou you understand what approx. (approximately) means?
About correction: correction (calculation) of %st values is made every time play list redraws, and of cause they may change (for example you may skip few seconds of current track, and other tracks will start earlier) and the deviation near 1 second is unavoidable, because time does not stay on a place.

P.S. I think DrO can tell more about this. But nobody knows when he again will please us with the presence in this thread.

[Pade2204]

well yes I know what it means.

but if you have one song playing - with 1 min left and the time is 12.00.

the 1 queued song (3 mins long) will start at 12.01
the 2 queued song (again 3 mins long) will start at 12.04
the 3 queued song (again 3 mins long) will start at 12.07

with %st approx (and yes it sure is approx) it look like this:

the 1 queued song (3 mins long) will start at 12.01
the 2 queued song (again 3 mins long) will start at 12.04
the 3 queued song (again 3 mins long) will start at 12.06

thats what I call approx. Oh well... If there is an explanation on this one, bring it on

I would like a non-approx %st please, hehe, Im very precise hehe.

And yes ofcourse there will be few seconds +/-, but whole minuts after just 3-4 queues is... too approx

[BugMaster]

Strangely. For me %st returns values in format hh:mm:ss so there is no 1 minute errors. I use %st [%N]%t text formatting in the playlist.

look at this screenshot:

[Pade2204]

BugMaster, you have the same error.

Look at the 1 queued song - its correct that it will start at 04.02:35, but the 2nd queued song will start at 04.04:29 (minor mistake), because the first queued song is almost 3 mins long.

But a bigger gap/error you see between the 2nd and 3th song (and so on).

the 2nd queued song will start at 04.04:29 and is almost 2 min long.

you see, your 3rd song is queued to start at 04.08:18 - thats almost 4 mins after the 2 mins long song.

Can you see what I mean ?

[DrO]

Originally posted by Pade2204
Jump to file v. 0.95.5 with Winamp 5.24
when having the above string (or any other with %st) and I press the "q" buttom in the playlist to queue, it sometimes shuffles away from the wanted song, and puts another song in queue. 1 out of 2 times it works ok.

i've seen that only a few times and never managed to reproduce it afterwards. the only thing i can think of is that it may be due to the internal cache re-updating and the code to display the position trying to update itself too soon. not quite sure how i'd be able to cater for such a situation and it may be something requiring a major re-code that i just don't have the time to realistically do. i'll see if i can do some control checks on accessing the internal queue list but i really don't know how it'll work.

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

now for the %st thing.
it's approximate since it calculates the next playing time based on the cumulative total of the queued track times which unfortunately will be out at most upto the current output buffer length of the selected plugin. this isn't something i can easily factor in since different plugins store their settings in different ways and i don't want to have to deal with that. so for my install i generally have a 1-2 second difference since my output buffer is at 1 second with silence stripping enabled (out_ds). so that covers why it's marked as approximate.

the code is designed to adjust the estimated start time as the currently playing song is adjusted so if you jump to 30 seconds from the end of the track then all following times will be adjusted to that.

there may be an issue with the time calculation code (just manually gone through BusMaster's screenshot and i think it's not working correctly from the start of the list and then it's correct for the rest of the way through but obviously will be out). so i'll have a double check when i can look at the code tonight or tomorrow so i can verify things and fix as needed. i was sure the code was correct when i last worked on it but i could be wrong *shrugs*

-daz

[BugMaster]

Pade2204:
You are right I don't notice that (May be I already sleep at this time )

DrO:
It is not very big bug. As I understand the problem is that added the time of the next song than needed (I think you make a mistake using [1+i] massive index instead of [0+i])
Also I found the bug, that %st can return for example 24:xx:xx
or even 25:xx:xx, but in my opinion in such situations it must return 00:xx:xx and 01:xx:xx. (May be I am wrong and that was normal behaviour.)

And now I again make a patch for correction of these 2 bugs:

[DrO]

the 24:xx:xx was incorrect and i've fixed the rounding handling in the code now. i've also spent the last 1h30 verifying the code and it looks like it's now working correctly as needed with it's calculations of the time of the next track. so that's another thing to check in the next build (which has no current eta until i get the other parts i need to get done are finished)

-daz

[Pade2204]

Many thanks BugMaster and DrO !

great jobs.

can I just replace the dll file ?