COWON J3 Firmware V1.24 (Standard)/standard Global V2.24/ V3.24 (DMB) / V4.24 (bokan)

[Peaceful1]

J3 Firmware V2.24(standard global version) direct link:here
Firmware V1.24(standard Korean version) direct link :here
J3 DMB firmware V3.24 direct link:here
V4.24 J3 bokan direct link:here

- Support .LRC lyric format.
- Expanded range of Slide show speed of COMIX (20sec -> 30sec).
- Fixed the error that player speed got slower while connected to USB adaptor.
- Fixed the playback error with some irregular mp3 files which contains overlapped ID3 tags.
- Edited some Chinese menu string.
- Changed Hebrew font.
- Fixed other bugs.
* LRC Support: save .lrc file into same folder and same name of audio files- <Audio File name>. lrc.

for more information : here & here

[MrAeronymous]

yay, .lrc <3

[DSperber]

Looks like they're never going to fix the M3U/MSC playlist defect which prevents music located on external storage from being successfully used as part of an M3U/MSC playlist. If present in an M3U playlist, these references to files on external storage are simply ignored.

So we're still limited to M3U/MSC playlists that only refer to usable music files on internal storage.

Also no mention of a fix for the failure to detect imbedded album art in tags of music files transferred to the J3 while in MTP mode, if you use MTP mode.

Would be nice if someday they'd modify the "tag info" display to actually also show the currently missing tag fields like (a) genre, (b) year, and (c) actual track number.

[reggub]

Originally Posted by DSperber

Looks like they're never going to fix

Also no mention of a fix

Would be nice if someday they'd

It's a good idea to post this on their official forum.

[LMX]

I was starting to wonder if 2.23 was Cowon's last J3 firmware update...

[DSperber]

Originally Posted by reggub

It's a good idea to post this on their official forum.

Took your advice and wrote up a new ticket there.

I'd previously expressed all three of these to them in earlier tickets. I realize that the M3U playlist problem is by far the most significant and difficult to resolve, but continuing to have an "officially undocumented" limitation on M3U playlists that restricts referenced music files to internal storage only is a major major defect, in my opinion, and should truly be addressed eventually. They've certainly heard about it from users for a long time now, and not done anything about it. To be fair, they did reply cordially to my ticket on this item way back when, including commenting positively on my suggestion for a method of possible implementation... stating "they would pass on my ideas to development".

As far as the MTP-related problems, well they don't affect me at all since I only use MSC.

But I would really like to see their "tag info" display improved, to show genre and year as well as the true track number from the tag meta-data fields. Hey, they added support for APE tags when I pointed out to them that they'd mistakenly supported playing APE files but not analyzing APE tags. And apparently, they added support for LYRICS when enough users apparently requested it. So why not add a few more fields to the "tag info" display... since they're already reading them for tag-based Music -> browsing and therefore already have the data present anyway?

Anyway, let's see if/when they respond to this latest ticket what they say.


I also added one additional new bug report: if you have ALL specified, and you browse by Music -> [Albums] and select an album folder, and you finish playing the last track in that album folder, that last track continues playing indefinitely (i.e. the timer just grows indefinitely) with no sound. Things do not happen as you'd expect at the end of any track, much less the last track with ALL specified (which actually I'd expect to see behave the same as FOLDER should since the browse started by Music -> [Albums]).

Note that if you have ALL specified, and you start the browse by Music -> [Artists], then for sure ALL is treated like FOLDER and the next thing that happens is determined by whether you have "play once" or "repeat" specified. But playback remains within the same album folder (i.e. ALL <-> FOLDER in this Music -> [Artists] type of browse), and ALL does NOT move on to the next album folder as the documentation describes .

ALL only truly moves on to the next album folder when expected if you browse by [Folders], and not by tag fields. Actually, if you browse by [Folders] then the FOLDER setting works like ALL! Playback will move on to the next album folder even if you have FOLDER set... just like you had ALL set. So FOLDER <-> ALL in this [Folders] type of browse.

Anyway, I've now reported this Music -> [Albums] and ALL combination which hangs playing back the last track of an album folder, just growing the track timer indefinitely and not producing any sound.

[demimurych]

1) Select radio station.
2) Set player to hold.
3) mute button dont work.
AGRRRRRRRRRRR


If i upload firmware under linux
firmware upgrade process FAILED
and player die.

Only rockbox utility save me.

[reggub]

Originally Posted by demimurych

If i upload firmware under linux
firmware upgrade process FAILED
and player die.

Try to update to J3's original firmware again, and then upload the firmware under linux and check if md5 is correct.

How can you use rockbox if it isn't out for J3?

[DSperber]

It appears that Cowon has unwittingly reinstated that same bug they had in 2.21, which failed to analyze music file tags and album folders for album art at boot time (either imbedded in tags or stored as cover.jpg in album folders).

The key clue here is that you do NOT see the "check albumart" function appear at boot time.

So there are now NO 95x95 miniature album art JPGs being stored in \System\MusicDB. As has been reported by several other users, I've now just confirmed this for myself, deleting everything in \System\MusicDB and rebooting. ZERO JPG's re-built into the folder.

This is apparently the same problem with 2.21, which they quickly fixed with 2.22.

I've reported this in a new ticket on their web site (others should do the same, to get them to fix it quickly).

For now, I suggest going back to 2.23 until they come out with a fixed 2.25.

[stonew5082]

it checks the art on mine, after the update. Try a factory reset maybe.

Originally Posted by DSperber

It appears that Cowon has unwittingly reinstated that same bug they had in 2.21, which failed to analyze music file tags and album folders for album art at boot time (either imbedded in tags or stored as cover.jpg in album folders).

The key clue here is that you do NOT see the "check albumart" function appear at boot time.

So there are now NO 95x95 miniature album art JPGs being stored in \System\MusicDB. As has been reported by several other users, I've now just confirmed this for myself, deleting everything in \System\MusicDB and rebooting. ZERO JPG's re-built into the folder.

This is apparently the same problem with 2.21, which they quickly fixed with 2.22.

I've reported this in a new ticket on their web site (others should do the same, to get them to fix it quickly).

For now, I suggest going back to 2.23 until they come out with a fixed 2.25.

[DSperber]

Originally Posted by stonew5082

it checks the art on mine, after the update.

Let's be sure we're talking about the right thing here...

The upgrade to 2.24 does not delete or lose anything already in \System\MusicDB. So all of your previously created 95x95 miniature album art JPGs will STILL be present. And that means they'll STILL be available for use by Matrix Browser.

It's only NEWLY ADDED art, after you upgraded to 2.24, which will NOT detected.

And the reason is that the "check albumart" function at boot time (which is when/where/how the newly added art is searched for and analyzed) is missing from the 2.24 boot sequence.

If you are currently upgraded to 2.24, and you delete everything in your \System\MusicDB folder, and then you re-boot, I would bet you will NOT see any JPGs reappear in \System\MusicDB as they should. And that's because the "check albumart" is being skipped at J3 boot time. And that means landscape mode will produce Matrix Browser with only the default "music note" picture in each of the (2x5) cells normally populated by your album art cover miniatures.

Go back to 2.23, repeat the identical process... and all JPGs are now fully created in \System\MusicDB as they should be.


Are you saying that on your J3 at 2.24, that the emptying of \System\MusicDB and then re-booting, WILL see the recreation of the 95x95 miniature JPGs in \System\MusicDB?

That would be astonishing to me, as a number of other users have already signed up to having experienced this same problem with 2.24.

Please clarify what happens for you if you delete everything in \System\MusicDB and then re-boot the J3.

[stonew5082]

Ok, I havn't done that yet, I'm just saying it SAYS checking album art at every boot, and I assumed you were saying it DIDN'T, but perhaps you are saying it APPEARS to but actually DOESN'T? If I test it i'll let you know.

Originally Posted by DSperber

Let's be sure we're talking about the right thing here...

The upgrade to 2.24 does not delete or lose anything already in \System\MusicDB. So all of your previously created 95x95 miniature album art JPGs will STILL be present. And that means they'll STILL be available for use by Matrix Browser.

It's only NEWLY ADDED art, after you upgraded to 2.24, which will NOT detected.

And the reason is that the "check albumart" function at boot time (which is when/where/how the newly added art is searched for and analyzed) is missing from the 2.24 boot sequence.

If you are currently upgraded to 2.24, and you delete everything in your \System\MusicDB folder, and then you re-boot, I would bet you will NOT see any JPGs reappear in \System\MusicDB as they should. And that's because the "check albumart" is being skipped at J3 boot time. And that means landscape mode will produce Matrix Browser with only the default "music note" picture in each of the (2x5) cells normally populated by your album art cover miniatures.

Go back to 2.23, repeat the identical process... and all JPGs are now fully created in \System\MusicDB as they should be.


Are you saying that on your J3 at 2.24, that the emptying of \System\MusicDB and then re-booting, WILL see the recreation of the 95x95 miniature JPGs in \System\MusicDB?

That would be astonishing to me, as a number of other users have already signed up to having experienced this same problem with 2.24.

Please clarify what happens for you if you delete everything in \System\MusicDB and then re-boot the J3.

[da1writer]

Meh, I find Cowon's way of doing the matrix browser (aka cover flow) to not be very well developed at all. Archos, Sony, and sadly Apple do a better job; faster, smooth, none forcing the user to be in a particular sorting format - which Cowon does with Forced album sorting and has painfully slow page processing. El Maco made a way better coverflow - very smooth and fast, pretty functional, and is even compatible with Aero Music. Sadly, I don't think Cowon will ever get better in this aspect as even with their D3, stock coverflow still sucks. Of course a few people deal with this fault as some users somehow do use it (proof of the newest posts on this thread and a few others), so this opinion of mine is probably just that. Personally, I could care less about them fixing their coverflow as I would rather them put their resources to fixing other bugs and playlist functions.

[DSperber]

Originally Posted by stonew5082

Ok, I havn't done that yet, I'm just saying it SAYS checking album art at every boot, and I assumed you were saying it DIDN'T, but perhaps you are saying it APPEARS to but actually DOESN'T? If I test it i'll let you know.

Well, maybe I jumped the gun here. If you say it actually DOES show "check albumart" then I'm mistaken. I had thought it didn't.

But maybe it just flashed quickly, or maybe I just didn't notice it if it was on the screen briefly ... when I was testing 2.24.

I had deleted ALL of my \System\MusicDB contents and then re-booted. No 95x95 covers made it back into \MusicDB.

When I backed off to 2.23 and re-booted, now it was very very obvious the the "check albumart" function was going on, because it was on the screen for quite a long time as my nearly 1000 album folders and "cover.jpg" files got analyzed and processed.

So if you say it actually DOES appear with 2.24, maybe it just nearly instantly falsely decides it has nothing to do and just moves on without ever actually working.

I stand corrected then, if that's the case. What's still true, however, is that the functionality of populating \System\MusicDB with those JPGs is definitely not working with 2.24.

[demimurych]

Originally Posted by reggub

Try to update to J3's original firmware again, and then upload the firmware under linux and check if md5 is correct.

How can you use rockbox if it isn't out for J3?

http://iaudiophile.net/forums/showthread.php?t=36073

I check evrything.
Under windows all fine.

If i upload firmaware under linux -
upgrade process failed