Print

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

[slipknot]

I now have my ipod fully synched with MC12 and I'm using the new caching feature with a size limit of 100gig.

Question: When MC12 finds the cache has grown too large (based on the user size limit setting), how does it select the files to delete from the cache?  Oldest?  Files where the track no longer exists in the MC library?

Tonight I renamed an album and re-synched.  After the synch I had CACHED copies of the track under the old name and under the new name.  This seems to mean that when tracks are removed from the MC12 library that they are not removed from the CACHE.

These obsolete files have no value anymore since the the source track no longer exists in the MC12 library.  They can never be synched, they are zombie files taking up space.

Now if MC12 would choose to delete these zombie files first when the cache size is reached, no problem here.

I just don't want zombie files to push me to my cache limit and then have MC start to delete valid cache file with these zombies taking up space that will never be used.

[slipknot]

Jim?  Matt?

[DarkPenguin]

A few things...

The clear cache button is your friend.

I go through and whack all the files that do not exist.  But note that if you change settings I do not catch that.  So if you're encoding to wma now I do not delete the mp3s.  But if you delete fred.ape I'll get rid of fred.*.

I delete based on modified date.  On each upload I change the update the modified date of the file.  So if you keep tranfering a given song it should not be deleted.  This will also take care of the zombie files.  As they will eventually fall out of the cache.

If a given transfer goes above the size of the cache I do not prune the cache until after the transfer.  (So if you move 150G of files I will not prune the cache until after the move.)

[DarkPenguin]

One other thing.  Since I put the rule stuff into place I have changed the directory it goes to at least twice.  Once to put it under a jrhhcache directory under the specified directory and another time to remove the [HHDevice] rule.  (Which is now accomplished via a check box.)

[slipknot]

A few things...

The clear cache button is your friend.

Why?  It takes 24 hours to convert all my ape files to mp3 for my ipod.  Clearing the cache defeats the purpose of the cache.

I go through and whack all the files that do not exist.

Manually?  How do you keep track of so many files in your head?

  But note that if you change settings I do not catch that.  So if you're encoding to wma now I do not delete the mp3s.  But if you delete fred.ape I'll get rid of fred.*.

Wouldn't rm fred.* get rid of any type file?

But like I described.  I renamed an album, so the tags changed.

After synching, I now have a dir in my cache for both the old album name AND the new album name and each dir has mp3 files for each track.  The old album cached files have no value, ever again.  So why are they still around?

Try it, do as I describe and see the result.

[DarkPenguin]

Why?  It takes 24 hours to convert all my ape files to mp3 for my ipod.  Clearing the cache defeats the purpose of the cache.

It is a cache.  Caches can be invalidated at any time.  If you do not wish to wait for files to fall off the bottom of the cache then you should clear the cache or manually delete files.  This is not a tightly coupled feature.  It is explicitly outside the application's database.  There are times it will be deleted by MC although I'm pretty sure there is a popup.

It is not a mirror.

Manually?  How do you keep track of so many files in your head?

No.

Wouldn't rm fred.* get rid of any type file?

Yes.

So, if you had fred.ape and encoded it to fred.wmv then change to encoding it as fred.mp3 then you'll have both fred.wmv and fred.mp3 in the cache.  If you later delete fred.ape then the cache will delete fred.*.

Or not, apparently.

But like I described.  I renamed an album, so the tags changed.

After synching, I now have a dir in my cache for both the old album name AND the new album name and each dir has mp3 files for each track.  The old album cached files have no value, ever again.  So why are they still around?

Try it, do as I describe and see the result.

It seems to work fine for me.

I'll add some logging under handhelds.

What are your cache settings?  What does the cache directory structure look like?

[slipknot]

It seems to work fine for me.

I'll add some logging under handhelds.

What are your cache settings?  What does the cache directory structure look like?

Like I said, I have albums that no longer exist in my MC library, but the folders and mp3 files still exist in my cache.

My suggestion would be to - after a synch is completed:

1  delete any files/dirs where the track no longer exists in the MC library.
2  delete the oldest files as necessary to keep the cache size within the configured limit.

Thanks.

[DarkPenguin]

What version of the player are you running?

[slipknot]

What version of the player are you running?

I just tried it with this latest version.  I see the cache files are now deleted that no longer exist in the MC library.  Cool.

It does leave empty directories though for the albums no longer in the MC library (minor).

Thanks.







Media Center Registered 12.0.100 -- C:\Program Files\J River\Media Center 12\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Unknown 2664 MHz MMX / Memory: Total - 2097 MB, Free - 1656 MB

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

Ripping /   Drive X:   Mode:Normal  Type:Auto  Speed:Max
  Drive Y:   Mode:Normal  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 X: CDWRITER IDE5232            Addr: 1:0:0  Speed:52  MaxSpeed:52  BurnProof:Yes
  Drive Y: ATAPI    DVD RW             Addr: 1:1:0  Speed:40  MaxSpeed:40  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:

[PDP8User]

I love your HH Cache!
In itself it's enough to make me upgrade, as I'll no longer have to maintain parallel libraries of lossless & lossy compression versions of my music.

But:
I have my cache set up as below, with no separate cache per device.
Why then must I have a device attached to build the cache? It takes some time and I'd prefer to be carrying the HH around listening to it while this is happening

If I attempt to build cache with no device, MC crashes abruptly

Cheers and keep up the good work.
Brian
 


System Info:
Media Center 12.0.106 -- C:\Program Files\J River\Media Center 12\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
AMD Unknown 2000 MHz MMX / Memory: Total - 1047 MB, Free - 408 MB

Internet Explorer: 6.0.2900.2180 / ComCtl32.dll: 5.82.2900 / Shlwapi.dll: 6.0.2900 / Shell32.dll: 6.0.2900 / wnaspi32.dll: 4.60 (1021) , ASPI for Win32 (95/NT) DLL, Copyright © 1989-1999 Adaptec, Inc. / Aspi32.sys: 4.60 (1021)

Ripping /   Drive D:   Mode:ModeSecure  Type:Auto  Speed:Max
  Drive E:   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 D: HL-DT-ST DVDRAM GSA-4163B   Addr: 0:0:0  Speed:40  MaxSpeed:40  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: Yes /

Portable Device Info
  Removed devices:

[envyc]

Add option to Scheduler for Handheld cache build?

I would like to see an option to either:-

1. Schedule the Handheld Cache build from within the MC Scheduler so that it only runs at selected times, or;

2. Only build the cache when there are available CPU resources / no user activity.

[DarkPenguin]

I connected a hand held.  I started building the cache.  I disconnected the handheld.  Cache kept building.

Do you have exact repro steps for the crash you're seeing?

I love your HH Cache!
In itself it's enough to make me upgrade, as I'll no longer have to maintain parallel libraries of lossless & lossy compression versions of my music.

But:
I have my cache set up as below, with no separate cache per device.
Why then must I have a device attached to build the cache? It takes some time and I'd prefer to be carrying the HH around listening to it while this is happening

If I attempt to build cache with no device, MC crashes abruptly

Cheers and keep up the good work.
Brian
 


System Info:
Media Center 12.0.106 -- C:\Program Files\J River\Media Center 12\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
AMD Unknown 2000 MHz MMX / Memory: Total - 1047 MB, Free - 408 MB

Internet Explorer: 6.0.2900.2180 / ComCtl32.dll: 5.82.2900 / Shlwapi.dll: 6.0.2900 / Shell32.dll: 6.0.2900 / wnaspi32.dll: 4.60 (1021) , ASPI for Win32 (95/NT) DLL, Copyright © 1989-1999 Adaptec, Inc. / Aspi32.sys: 4.60 (1021)

Ripping /   Drive D:   Mode:ModeSecure  Type:Auto  Speed:Max
  Drive E:   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 D: HL-DT-ST DVDRAM GSA-4163B   Addr: 0:0:0  Speed:40  MaxSpeed:40  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: Yes /

Portable Device Info
  Removed devices:

[rpalmer68]

I connected a hand held.  I started building the cache.  I disconnected the handheld.  Cache kept building.

Do you have exact repro steps for the crash you're seeing?

Easy!  Just cancel the cache build and start it again without the Handheld connected.

MC will crash (I'm using build .165)

Richard

[DarkPenguin]

The dreaded null pointer.  Next build.

[Craig]

While we're talking about the cache,
If I re-rip a CD and replace my original files, The cache version of the file is not reconverted when a handheld sync takes place.

This means that badly ripped tracks will stay on the handheld untill the mp3's are deleted from the cache.

Craig

[DarkPenguin]

The cache files are not in the database.  Clear the cache when such things are done.

[Craig]

But tags in the cache get updated, isn't it fair to assume that the files themselves should be?

Craig