Print

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

[yonkiman]

To save wear and tear on my new SSD, and also to speed up format conversion when synching my RockBox, I've assigned all my JRiver Temp folders to my 4 gig RAM disk.  4 gig should be plenty of room for a temp folder, right?

Well, I'm not so sure.  The converted files are being created and stored in the temp folder as expected.  Then they are transferred to the RockBox as expected.  But they aren't being deleted after they are synced to the rockbox.  I'm trying to sync about 40GB of music, and my 4G ramdisk already has 570MB of ogg files in it.  At this rate, the ram disk is going to fill up after onlytransferring about 10% of my songs, at which point something undesirable (somewhere between exiting with an error message and a system crash, I'd imagine) is going to happen.

So I just wanted to clarify how the temp directory works.  If I want to convert & sync 200GB of FLACs to 40GB of OGGs on my music player, does my temp directory actually need to be able to hold 40GB of data?

If so, an option to delete every file from the Temp directory immediately after syncing each file would be very helpful!

Cheers,
Fred

[yonkiman]

Well I can now tell you what happens - you get a bunch of "Unable to stack file / The stack drive is low on space" pop-ups when the temp directory is full, and syncing stops until you delete the files in the temp folder to free up room.

It sure would be great if MC either:

• Deleted files from the temp folder as soon as they were used and no longer needed, or
• Supported a "max temp storage" parameter that would guarantee MC never used more than xxGB of temp storage.

My 2 cents...

-Fred

[glynor]

Modern MLC flash drives use a number of strategies to prevent NAND burn out due to frequent writes.  Modern SSD (Intel G2, Indilinx, and later controller series) drives with MLC flash are estimated to last 20-50 years under most "common" system drive use cases.  Even if you assume you are an "abnormally heavy" writer to the disk, you can still count on at least 5-7 years of use under abnormally harsh conditions, which is comparable or better than you would get with magnetic storage.  More information here: http://yabb.jriver.com/interact/index.php?topic=59912.msg404749#msg404749

The take away?  Don't worry about that.  A big hunk of the benefit of an SSD is the everyday benefits you see from temp and swap file access speedups.  The only people who need to worry about that stuff are server admins on database servers that do thousands of tiny little writes every minute for hours on end.

[yonkiman]

Yes, and CDs will last 100 years.   :-)

OK, so I apologize for not being more specific when I said "wear and tear".  You may well be right about the SSD lifetime, but even if you are, my RAM disk is still a lot faster than the SSD - I would estimate converting ~200GB of FLACs to ~40GB of was running 1.5x to 2x faster than it was when I was trying to do it all on the same drive.  It's also not "fragmenting" my SSD drive (I don't expect you'd disagree that the more you use SSDs, the slower they get, hence the need for TRIM, which isn't supported by Windows XP or by my Gen 1 Intel X-25M SSD).  Finally, needing 40GB of temp space to transfer 40GB of songs seems pretty inefficient.

Thanks for your clarification and the opportunity for me to be more clear as well.

-Fred

[JohnT]

I think maybe you set your "Tools / Options / File Location / Conversion Cache" to go to the temp folder?  If so, I don't think that's what you intended since the conversion cache does not get deleted, it's used to keep a converted version of the file around to greatly speed up future device syncs.  If you want to keep a conversion cache, set it to a folder with sufficient space, if you don't want it to be created, just set it to "None" and the temporary converted files will get deleted after each file is transferred.

[glynor]

It's also not "fragmenting" my SSD drive (I don't expect you'd disagree that the more you use SSDs, the slower they get, hence the need for TRIM, which isn't supported by Windows XP or by my Gen 1 Intel X-25M SSD).

No I certainly wouldn't dispute that.  NAND does certainly have to contend with the block rewrite penalty.  It does drive me absolutely crazy that some quarters (mostly PCPerspective) refer to this issue as "fragmentation" though.  Fragmentation has very little to do with the issue at all (which I expect you know since you enclosed the word in quotes).  In fact, you can easily reproduce the issue on a completely blank drive (which obviously has no files to be fragmented).  The "sector remap fragmentation" issue was corrected by a firmware update on the Intel drives, and isn't directly related to the block rewrite penalty issue that TRIM addresses.  I generally like PCPer, but often their storage reviews are quite littered with inaccuracies and oversimplifications (and their graphics reviews are solidly in Nvidia fanboy territory).

If you're curious about the actual cause, Geoff Gasior did a great explanation write up here: http://techreport.com/articles.x/16848/2

But, yes, using a RAM disk in this case would be one means of dealing with the lack of TRIM on an old G1 Intel drive or similarly "non-Trimmable" drive.  I think John T has a good point above regarding your specific issue, but perhaps the real issue is that you need more than 4GB on your RAM disk...  That's a tough one.

[yonkiman]

I think maybe you set your "Tools / Options / File Location / Conversion Cache" to go to the temp folder?

Ahh...that could well be it (will check when I get home).  So if I set this to "None", does it really slow down all future device syncs?  I was assuming that if the file was already on the device, it would just be left alone during future syncs, and that the only time having all the songs cached would speed anything up is if you were syncing to a different device, or had cleared/formatted your original device and were re-loading songs.

Thanks for the info John!

-Fred

[JohnT]

I was assuming that if the file was already on the device, it would just be left alone during future syncs, and that the only time having all the songs cached would speed anything up is if you were syncing to a different device, or had cleared/formatted your original device and were re-loading songs...

That's exactly right.

[yonkiman]

That's exactly right.

Cool.  So my final question:  When it's converting a song on-the-fly, and cache is set to None, does it do it all in RAM or is it writing an intermediate file to a disc somewhere?  Going back to my original point, I'd like to keep all large "temporary" operations off my SSD (in either RAM or traditional hard disk) if possible.

Thanks,
Fred

[glynor]

I was assuming that if the file was already on the device, it would just be left alone during future syncs

One little note.  You will probably find that you need to disable Resync if Date Modified has changed.  I've found that this option causes MC to resync files quite often if you have tagging changes saved to the files.  That's because many of MC's tags are updated on the fly when simple things like playback occurs.

[JohnT]

Cool.  So my final question:  When it's converting a song on-the-fly, and cache is set to None, does it do it all in RAM or is it writing an intermediate file to a disc somewhere?  Going back to my original point, I'd like to keep all large "temporary" operations off my SSD (in either RAM or traditional hard disk) if possible.

Thanks,
Fred

It creates a file in the Media Center temp folder which is in the user/appdata/roaming/j river/media center 15 area.

[yonkiman]

It creates a file in the Media Center temp folder which is in the user/appdata/roaming/j river/media center 15 area.

I'm sure you can see this question coming from a mile away  :  Can you change the location of that temp folder?

[glynor]

Options -> File Locations -> Program Files -> Temporary Files

[yonkiman]

<A bunch of helpful messages>

Thanks for all the advice and info, glynor!

-Fred