New Karma Firmware Released!
Apr 8, 2004 at 6:37 AM Thread Starter Post #1 of 12

Bolt San

500+ Head-Fier
Joined
Feb 29, 2004
Posts
959
Likes
10
http://www.rioaudio.com/support/rio/...rmware_168.exe

Firmware Changes Since v1.41
----------------------------

Fixed an issue whereby files randomly disappear from Pearl. Any such files should reappear after loading this update. You should also updated to the latest Rio Music Manager.

Artist names starting "The " or "A " - or the French or German equivalents - will be sorted into content lists using the subsequent noun.

Press & hold "Play Music" to jump direct to the content list from which music was last selected.

Tracks greater than 240 minutes in length now play back and seek correctly.

The shuffle algorithm is no longer weighted toward tracks heard least recently - it is now random and unbiased.

Fixed an issue whereby seeking through the track would occassionally continue after the button was released.

Eliminated audio pops when scrolling through different EQ presets.

Fixed an issue whereby a reboot would occur should the user unlock the unit and immediately press the menu button after a transfer had completed.

More MP3 tracks now play back gaplessly.

More Ogg Vorbis tracks now play back gaplessly.

Text scrolling is no longer jerky with EQ on.

Fixed an issue whereby in Rio DJ music from 1800s (classical) was not displayed when using "Sounds of...".

Lists no longer mis-sort entries that start with accented characters.

Ogg Vorbis 48 and 56 kbps tracks no longer sound garbled.

Multi-stream Vorbis files no longer crash the player.

Fixed a stability issue while playing 22050Hz MP3 tracks.

Database rebuild no longer erased track profiles.

In Play Music > Artists, the user can now select tracks that lack Album info.

Fixed a stability issue upon pressing the RioStick after a completed transfer.

Improved stability while playing back certain damaged MP3 files.

Player no longer returns to the start of track after communicating with the PC.

Fixed an issue whereby the running order would occassionally be reset after a transfer.

Fixed an issue whereby selecting a bookmark would occassionally crash the player.

Fixed an issue whereby rewinding through several tracks would sometimes ocassionally cause the seek function to stop working.

Fixed an issue whereby an ethernet transfer would occassionally hang after the transfer of several tracks.

Fixed an issue whereby certain FLAC files would cause playback to halt, requiring a power cycle.

Added code to shut down the player automatically in the event of a disk problem (for example, if the player were dropped while accessing the disk). The player can be restarted as normal provided the disk has not been physically damaged.

Fixed an issue whereby the player could shut down when attempting to play a very large playlist.


RMML (Java applet) Changes Since v1.41
--------------------------------------

Rmmlrc's parent folders are properly created (no more security warning).

Cache last modified date saved in the new way (last modified date of file vs in a separate file)

Bunch of jEmplode-only classes removed

.rmmlrc moved to "C:\Documents and Settings\<yourusername>\.openrio\rmmlrc" on Windows or "~/Library/Application Support/Open Rio/rmmlrc" on OS X

The player database is now cached on the local machine, so subsequent reads (assuming there have not been database changes) will load off of the local filesystem. This can be disabled by setting cacheDatabase=false in rmmlrc.

Broken tunes will show up in RMML (though still broken until the next firmware, or until you run riorepair). You can find them by doing an advanced search for "type = illegal".

Fix for parsing track number in ID3v1.1 tags.

Download filename formats are per-type:
jempeg.filenameFormat.tune (default = {artist}-{source}-{title}{ext})
jempeg.filenameFormat.playlist (default = {title})
jempeg.filenameFormat.taxi (default = {title})
jempeg.soupFilenameFormat.tune (default = {artist}-{source}-{title}{ext})
jempeg.soupFilenameFormat.playlist (default = {title})
jempeg.soupFilenameFormat.taxi (default = {title})

... and as a result, downloads from taxi no longer try to format the filename as {artist}-{source}-etc (so you don't end up with filenames like '--yourfilenameontaxi'.

advanced search functions:
now[] = returns the current time in seconds from epoch
daysago[x] = returns the time x days ago in seconds from epoch
secondsago[x] = returns the time x seconds ago in seconds from epoch
minutes[x] = returns x * 60

ex: ctime > daysago[5]
would return all tunes created in the past 5 days

Note: you must not have a space between the function name and the brackets or the brackets and the value -- the parser is rather finicky (for example, it must be 'daysago[5]', not 'daysago [5]' or 'daysago[ 5 ]'.

Fixes for file generation for people who switch back and forth between RMML and RMM.

Better support for tag extraction in cases where the file type is ambiguous

Support for riorepair (the database can optionally not toss out bad nodes)

Refactoring to clean up 3rd party apps

Runtime memory usage significantly lowered

Miscellaneous performance improvements

Disabled brushed metal LnF by default due to a bug in Apple's impl (dragging anywhere in dialogs drags the entire dialog). To reenable, you can run java
-Dawt.apple.brushMetalLook=true -jar rmmlite.jar

OS X accelerator for Delete is mapped properly

Accelerator for properties is Cmd-I on OS X now

Save As... has an accelerator now (Ctrl/Cmd-S)

RMML attempts to discover Karmas on all network interfaces now

Discovery dialog has a Cancel button

"Cancel" on cancel button is internationalized now

Regression - Changes to tags weren't firing tagModified events (so soups weren't updating on changes)

Changed UI on free space progress bar because on OS X the default UI is animated, which was churning processor at idle

Fix for FLAC w/ ID3v2 tags

Fix for infinite loop caused by certain invalid ogg files

XML exporter supports configurable character encoding (for riodump)

Optionally disable deduplication

Optionally enable updating of tags for duplicates

Character encoding fixes for the Japanese resource bundle

Support stripping of non-English articles

Parse description.xml from discovered devices

Repair corrupted Japanese resource bundles

Always parse ID3v1 tags in the default locale

Japanese ID3v2 tags that lie and say they are ISO are parsed as default locale
NOTE: If your default Locale is Japanese, this is true by default. If you want to turn off ISO turning into default locale, edit ~/.rmmlrc and set the property
"treatISOAsDefaultEncoding=false" (you may need to add this property if it doesn't already exist)

Always interpret Ogg comments as UTF-8 (rather than default locale)

New .rmmlrc setting "recycleConnectionBeforeDelete" that allows you to bypass the workaround for a rare problem where if you add a node and delete it in the same connection, it causes strange problems. If you don't care, you can set this value to "false" and it makes deletes much faster

Added "Close" button to sync dialog

New locale.language, locale.country, and locale.varaint .rmmlrc settings that let you override your default locale

Disable the close button on the discovery progress dialog

Renamed "size" tag to "playlist size"

Fix for certain ID3v2 tags that were parsing as negative lengths (and ID3v2 parsing would then fail for that file)

RMML will attempt SSDP search for device

Don't display error to user about playlist that contains missing FID

Fixes for UTF-16LE/Kanji in ID3 Tags

Renamed Japanese resource bundle to correct name

Fixed IndexOutOfBoundsException for titles that contain only spaces

Allow files that are named *.mp3 to be parsed even if they fail the first-pass MP3 header test
 
Apr 8, 2004 at 8:09 AM Post #2 of 12
And the Karma users always said there wasn't any problem with that player
wink.gif

But it's cool that all those things are solved.
 
Apr 8, 2004 at 8:45 AM Post #3 of 12
Quote:

Originally posted by Megaman
And the Karma users always said there wasn't any problem with that player
wink.gif


??? Do you see anything major in there? Software gets constantly updated (when it does get updated, that is) and minor fixes are commonplace in development...
confused.gif
 
Apr 8, 2004 at 3:09 PM Post #4 of 12
Quote:

??? Do you see anything major in there?


I guess it depends on who you ask ...if you asked me, I'd say yes because a bunch of those things would really disturb me. But anyway, not why I'm replying...I'm curious to know about these two particular things..well, really one (you'll see why):

Quote:

More Ogg Vorbis tracks now play back gaplessly.


Quote:

More Mp3 Vorbis tracks now play back gaplessly.


I never heard anyone saying that there was anything wrong with the gapless function. What's up with that ?? My main concern here of course, is that with the news of the IHP getting gapless playback, if the Karma wasn't doing it right for all this time, my faith in the Iriver engineering staff (one dude probably) isn't too strong, and I'm afraid that the pooch will get proverbially screwed here.

What about certain Ogg or Mp3 files wasn't being played back gapless/properly ?
 
Apr 8, 2004 at 3:16 PM Post #5 of 12
Quote:

Originally posted by gorman
??? Do you see anything major in there? Software gets constantly updated (when it does get updated, that is) and minor fixes are commonplace in development...
confused.gif


I was kindda joking, but since you asked me, I can see it used to had alot of stability problems.. good thing the player is more reliable now
cool.gif
 
Apr 8, 2004 at 3:21 PM Post #6 of 12
Quote:

Originally posted by Megaman
I was kindda joking, but since you asked me, I can see it used to had alot of stability problems.. good thing the player is more reliable now
cool.gif


Sure, but among the many bug fixes, there were very few that affected a large number of users... anyway, if you were joking...
tongue.gif
 
Apr 8, 2004 at 3:57 PM Post #7 of 12
My have just fixed gapless at a few strange bitrates or strange cases. I never noticed problems with gapless playback before (mainly use FLAC and high VBR mp3's though), but any fixes are welcomed.
 
Apr 8, 2004 at 4:31 PM Post #8 of 12
Thanks for attempting to answer my question ian. I guess IHP'rs will just have to grin and bear with the comming updates no matter how flawed they may come out to be. Hopefully not at all but that's really just like thinking that miracles really do happen.
smily_headphones1.gif
 
Apr 8, 2004 at 5:07 PM Post #9 of 12
Most of these issues are issues experienced by a subset of the user base... not all Karma owners.

The gapless is not perfect but it works most of the time... even when it doesn't work it's only a very very minor "tick" that is audible... nothing close to a pause so it's way better than every single other HD DAP out there even in that regard.

The only firmware issue I have is with bookmarks working (they don't). Used to lock up my Karma... now they just don't save after this firmware upgrade...

With Audible support on the horizon they need to get this working... again... this does not happen with all users to my knowledge.

But that's hardly a showstopper in my book.

The playlist support is phenominal... you can build/edit/delete on the fly. You can also insert, reorder, delete and append to while a playlist is PLAYING. Marvelous.
 
Apr 8, 2004 at 5:33 PM Post #10 of 12
Just want to share my good experience with the Karma. I've had it for four months now and never had a single problem (knock on wood) - haven't reset it EVER. I actually spent some time justifying whether I should even bother with this firmware update because even with my heavy use (7+hrs a day), I'm of the opinion that if it ain't broke, don't fix it. Nevertheless, I welcome all the minor fixes
 
Apr 8, 2004 at 7:41 PM Post #11 of 12
You should, tim.
It doesn't really say it there, but there's one major change.
It seems they tweaked the database system, and now browsing the play music section is completely gapless, there's no delay at all.
I don't know how they did it, but the extra speed is amazing.
 
Apr 9, 2004 at 3:49 PM Post #12 of 12
Quote:

Originally posted by Sweet Spot
What about certain Ogg or Mp3 files wasn't being played back gapless/properly ?


In very rare cases (I can think of two files on my Karma), the transition between .ogg files had a very slight hitch, but that's it.

It's also worth mentioning that the Karma does gapless playback for files that weren't even encoded gapless in the first place. I have a couple of old albums that I encoded with Bladeenc a while back, and the Karma plays them straight through with no gaps.
 

Users who are viewing this thread

Back
Top