Peter says FITNR.

Actually, that was a different, player-side bug -- although caused by the same underlying misunderstanding (by a different person!). The emptool/emplode bug, which affected all very-low-bitrate VBR files, is now FITNR too.

Peter

In reply to:

---

Every time I open something in the right-hand pane, the columns all go back to the same size instead of how I'd stretched them before.

---

Have you tried this in 42 by any chance? I thought this was fixed (at least it is for me using JDK 1.4).

Have you tried this in 42 by any chance?

I'm holding off until some of the other bugs people have been talking about are fixed. For instance, it's critical to me that {pos:2} works in all cases, but others have said it doesn't work for them.

Am I missing anything?

I would love it if Jemplode could read the contents of the 3 bookmarks
and make them appear like playlists attached to the playlist tree.
Kind of like the soup lists are.

Then you could make a playlist from the front panel and save it is a bookmark,
then next time you open jemplode, you would see the playlist you created.

I don't know how the Bookmarks are stored,
but I can only imagine that they are readable.

Is this possible?

Haven't even used bookmarks before I would guess they're stored in config.ini, though.

No, they're not stored in config.ini, at least I don't see them there.

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=4&faqent=129#129

its probably stored in the mysterious /dev/hda3 partition.

perhaps for this purpose, jEmplrode might be able to uncover the mysteriousness of said partition,
What's so mysterious about it anyways?

its the scratch partition that the player software writes non-flash info (all statistics including plays, marked, etc.) using sector-level access.

OK, so perhaps, Jemplode could decode all of this information for us???
Perhaps we could then be able to actually edit the number of plays for a given track,
so we can also get rid of those unsighly tracks marked "plays: 65,536" ?

you should already be able to from the advanced tab on the properties dialog ... i think

you should already be able to from the advanced tab on the properties dialog ... i think

mmmm. NNot sure on that one,
I remember being dissapointed that I could not change this,
but I have not checked the most recent version,
will get that tomorrow and test......
thanks Mike.

I have a request... In previous versions there used to be selections under Playlists tab on the left for Playlists, Artists, Albums, Genres, Years, Artists/Albums, Searches, All.. In the new versions these views are not possible..

Maybe I am missing something but Can we get these views back as an option?

They don't appear by default anymore (though I may create some default ones in 44 if you don't have any setup).

If you go to Tools=>Add Soup Playlist... then give the playlist a name ("Artists") and click "Add Tag Layer" and select "By Artist" that will create a soup view for Artists. Likewise you can go and add several layers to make more complex views of the player.

Mike

That is what I needed..... Thanks...

Talking of soups, would it be possible to exclude them from the exported XML?

The reason I ask is that when I was testing my changes to the XML exporter, the diff suggested that I'd changed a lot on my player because the soup views get different FIDs each time.

Or perhaps we could have a different format for FIDs for (off-player) soup playlists? Don't know whether you use integers internally for this.

Yeah ... in fact, when you're looping through FIDs, I think you can call .isSoup() on the IFIDNode to know whether or not to skip it ... I don't remember if that is done in the Abstract one or in each of the concrete classes.

For those who care about this bug, once the NR comes out where it is FI, I'll port the bugfix and it will be FITNR for me too

Please could we have JEmplode use "Sort by Position" for new installs and whenever the "Set Playlist Order" function is used?

just to add to this request: it would be nice to have independent sorting for each soup. (i.e. one soup sorted by tracknumber, and another sorted by title).

thanks
-ted

Yeah, I tried this, and the Advanced tab is the only place that this information is editable.
I changed the plpays value from 65535 to 0 and hit OK.
The tune turned red, annotating that it had been changed, and I did a sync.
The tune was still marked plays:65535.
PLEEEEAAAAZE fix this. If you need me to do any sort of testing, let me know.

- thanx

Just out of curiosity, did you hti "enter" after changing the value of the play_count in advacned? There appears to be a bug in the advanced view that if you just change the value and hit OK without hitting enter first, it won't save the value. When i did this, I was able to update play_count.

Mike

I cannot confirm nor deny that, senator.
However I will test it this evening.
- thanks

Hmmm whats the chance of getting some VBR header fixxing code added
would be really nice to be able to select a file with a dodgey header and jsut hit - fix vbr- and have it do all the work on the player

what types of VBR problems?

Like, for example, when the VBR TOC is complete tosh, maybe?

The problem with this is that the file would effectively have to be completely read back from the player. This wouldn't be such a problem with Hijack installed -- you could just grab it with FTP, I guess. It would be quite slow over the normal protocol.

On my list of things to do in my copious free time is a VBR fixer that you run on the player at a shell prompt, that would fix up all the duration/bitrate tags in the *1 files as well.

In reply to:

---

On my list of things to do in my copious free time is a VBR fixer that you run on the player at a shell prompt, that would fix up all the duration/bitrate tags in the *1 files as well.

---

I was about to ask for one of those (at least the latter half), so if you get some CFT....

OTOH, if I get some first, I might have a go.

In reply to:

---

9) reliable deduping

---

Hey Mike, how is this coming? I have been holding off on re-uploading all my stuff because I assume you are going to change the dedup method and the checksums would be off so I would have to re-upload everything again. Just curious when this might get more or less stable.

Thanks,
-Mike

honestly, the next major release will be several weeks out (I have another home project that I will likely be working on for a little while)... what I can do, though, is plan to at least provide an easier upgrade path that will recompute the hash value for the songs you already have uploaded (granted this will take just as long as reuploading, but without the hassle).