Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[phoenix91]

I made a definition of a network-drive directory as a handheld (x:\MyMusicMP3) under Drives&Devices. I use this 'handheld' to synchronize all my .ape files to .mp3
Since I switched from MC11 to MC12 (12.0.279) a couple of days ago, all in the synchronization process created files get a trailing number.

As an example,  the file
"11 - Walking The Wire.ape"
results in the filename
"11 - Walking The Wire12783729.mp3".

I do not use the handheld conversion cache.
Is there a way to switch off this behaviour or do I miss something?

Any help is appreciated

U.

[JimH]

I don't think that's MC doing it.  Maybe the MP3 encoder?  Did you set special options for it?

BTW, MC12 can be set to use a cache for this purpose now.  See the options for handhelds.

[benn600]

MC has been doing this for me for a long time.  It is MC but could be LAME, who knows.  Any way to disable it?  I don't really care but it seems unnecessary.

[phoenix91]

Hi Ben, that were you. I remember your postings, a couple of month ago, but couldn't find them when I scanned the forum yesterday.

To JimH:
I don't think I'm using any special Lame settings, as you can see below. Problems still persists when I change to other vbr settings (high, extreme).


The problem occurs only with ape to mp3 conversion using the handheld synchronize functionality of MC12.
With Tools -> Library Tools -> Convert Format and the same Lame settings, everything is fine.


My system Info:
Media Center Registered 12.0.279 -- d:\Media\J River\Media Center 12\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Pentium 4 1717 MHz MMX / Memory: Total - 785 MB, Free - 219 MB

Internet Explorer: 7.0.5730.11 / ComCtl32.dll: 5.82.2900 / Shlwapi.dll: 6.0.2900 / Shell32.dll: 6.0.2900 / wnaspi32.dll: 4.71 (0002) , ASPI for Win32 (95/NT) DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0002)

Ripping /   Drive F: _NEC    DVD_RW ND-3551A   Mode:ModeSecure  Type:Auto  Speed:Max
  Drive G:   Mode:Normal  Type:Auto  Speed:Max
  Drive H:   Mode:Normal  Type:Auto  Speed:Max
  Drive I:   Mode:Normal  Type:Auto  Speed:Max
  Drive L:   Mode:ModeSecure  Type:Auto  Speed:Max
  Drive R:   Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No 

Burning /  Drive F: _NEC     DVD_RW ND-3551A    Addr: 2:1:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Drive R: HL-DT-ST DVDRRW GSA-2166D   Addr: 4:0:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /

Portable Device Info
  Removed devices:

Device info dump for 'MyMusicMP3':

WMDMName:
DeviceUID: {B1EF6842-562E-48C5-914D-C9107BA49C5E}
CanonicalName:
VendorName: ; VendorID:
ProductID: ; FirmwareVersion:
WMDMSerialNumber: NULL
DeviceType: 4; DeviceID: ; DeviceName: ; UnsupportedDevice: 0
IsDrive: 1; DriveLetter: ; DrivePath: W:\My MusicMP3; MainDriveLetter:
IsJanusCapable: ; IsIpod:
SupportsAlbumArt: ; AlbumArtEnabled: 1
SupportsFolders: -1; PlaylistFormat: 0; EjectMode: ; AlwaysPumpCOMMessages: 0
SupportedFileTypes: mp3;wma
ContextMenus:
MemoryTypes:
InstallURL:
ApplicationName: Media Center
ImageName:
RootBasePath:
AudioBasePath: [Artist]\[Album]\
ImageBasePath: Images\
VideoBasePath: Video\
DataBasePath: Data\
PlaylistBasePath: Playlists\
DatabaseBasePath: Database\
AudibleBasePath:
MatchKeyExpression: If(IsEqual([Media Type], Image), [Name] [File Size, 0], [Name] Clean([Artist], 1) [Album] [Genre] FormatNumber([Track #, 0]) [Media Type] )
ChangeKeyExpression: [Rating]

Interface Plugins:
  Library Server (Active)
  TiVo Server
  UPnP Server (Active)
  Playing Now (Active)

[Mr ChriZ]

I've seen this recently too, doing my synchronize to Mp3 library.
Not got round to mentioning it.   Fairly sure it's MC.

[Mr ChriZ]

BTW, MC12 can be set to use a cache for this purpose now.  See the options for handhelds.

Out of curiosity what are the advantages to using the Cache?
I never liked the idea of it because to me Cache instantly says Temporary, for fast access...
Although that's probably not correct.

Where as with the handheld system I see exactly what's happening,
where it's going etc, it works better in my head.  I can synchronize it to
make it up to date, see what's not up to date...

[benn600]

I also don't like the cache.  I am a big proponent of refreshing things and often like to wipe devices to start over...therefore, the last thing I would ever want is a cache.

I have much bigger feature requests that I'm really pushing for.

This is an annoying feature--mainly on flash drives where I am mainly going to be playing directly from the files as I am temporarily on another computer and don't want to install MC for library client access.

[robydago]

Out of curiosity what are the advantages to using the Cache?

I never used it or read anything about it, but I think\guess that is there so that things like conversion to different bitrates don't have to be done at each sync.
But maybe it has other\different advantages... I really have no idea!

[phoenix91]

The cache can be quite useful to speed synchronizing up, I think. Especially on a rather slow computer like mine, where converting (transcoding) to mp3 takes really a bit of time. There are a couple of MP3 players in my family and the cache is going to save me some time. The synchronize time for the second and up player should reduce to the time amount for copying the files from the repository to the handheld. At least I hope so.

But unfortunately I'm not at this point. There is this filename-number issue I would like to get rid of. Thank to Benn600 and MrChriZ I'm not alone on this world.
Please JRiver team, cast an eye over this problem.

[benn600]

Believe me, mp3 conversion takes a while on any home computer system.  It just does.  And then multiply that times the 1K + songs users sync and you've got hours of waiting.

[DarkPenguin]

Took a stab at this.  282 or later.

[benn600]

Would you mind please adding a cover art resize feature so that large cover art is down sized to 320x320 pixels?  I am really trying to ask for this as much as I can...I'd really appreciate it.  Just a checkbox for each handheld sync device.

[DarkPenguin]

Would you mind please adding a cover art resize feature so that large cover art is down sized to 320x320 pixels?  I am really trying to ask for this as much as I can...I'd really appreciate it.  Just a checkbox for each handheld sync device.

The hh cache doesn't deal with cover art.

[phoenix91]

Would you mind please adding a cover art resize feature so that large cover art is down sized to 320x320 pixels?  I am really trying to ask for this as much as I can...I'd really appreciate it.  Just a checkbox for each handheld sync device.

I totally support the idea for this feature. There has to be a way, at least in a next release.

[benn600]

The hh cache doesn't deal with cover art.

I understand that but I would very much appreciate a cover art resize feature.  There is no even remotely easy method for me to trick MC to copy low-res cover art to my handhelds.  It copies the huge, full resolution files.

I feel that 320x320 would be a good resolution of choice.  It provides plenty of resolution for basically every device I can think of...iPod's need even less than that and the iPhone appears to use exactly that since it shows cover art at 100% width, of which the screen is 320 pixels wide.  It would copy just the right amount of data and would LITERALLY save me 2 GB of my 8 GB iPhone.

My average cover art is 1.3 MB at 1200x1200 resolution ... close to 1,500 songs.  The huge cover art file gets copied to every single song, so it quickly multiplies out to even more of a space requirement than my server, which only stores one copy as folder.jpg.  The handheld gets an embedded copy in every song.

Please!

[DarkPenguin]

This was a hh cache issue.  If you want a new feature try a new thread.

[benn600]

Sorry but I have tried asking for this feature every month pretty much all year long (or so).  I just don't think it will ever get added so I was hoping to sneak it in here.  Once someone at J River starts following a thread, they read every post...I'm the same way, you scroll down looking for that special icon indicating you've posted there...so I hoped you would read my plea.

[gregoryx]

Took a stab at this.  282 or later.

So this is fixed in 282 or later?

[phoenix91]

Just installed .294. The naming issue is fixed. Thanks to the JRiver team.