Print

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

[kewe65]

Sort of related to this topic I posted a couple days ago around the use of RemotePlay (I think)

http://yabb.jriver.com/interact/index.php?topic=65500.0

I noticed that the library has the cached/converted to mp3 files showing up automatically as duplicate entries with different paths.  The path to the cache folder is not included in the auto import folder list.

I believe its related because the songs played with RemotePlay (actually on iPhone and the TouchPad) are the songs that are showing up in the library (all views, btw).  They actually show up as stack items.

Thanks

[kewe65]

Any thoughts on how to exclude these folders from getting included in the library.  There is nothing actually pointing to the drive or folder for the conversion cache so don't understand why they are getting imported automatically.

What's the benefit of having the conversion in the first place?

[MrC]

The conversion cache gets created when music is streamed to a device which is configured for conversion of audio (eg. DLNA, LS, etc.).

If you don't want the cache, disable it in Options > File Location > Conversion Cache > Audio > Cache location: None (do not create cache)

I believe the cache files are added as stack files.  You can always expand the stack files, or use rules to show only non-top of stack files, and delete them.  But this would be an endless exercise if MC continues to create them due to settings.

[lepa]

But why add cache files to the library in the first place? IMO these files should be invisible for the user. When needed MC should just use already existing cache file and if it is not there just make a new one. I see no reason to "pollute" library with these stacked files.

[MrC]

By default, the cache files will be hidden from the stock views as they are non-stacktop items.

But you can view items via view schemes to suit your needs.  You can create views to hide cached files, or you may want to only see or play only these converted files for transferring or alternate zone purposes.  Create views that suit your needs.

For those of us with large libraries, recreating cache files is very time consuming (almost 24 hours here), so MC provides a means to create them once, and it manages them for future use.

It is not clear to me how MC could both know about and use existing cache files, but not store a notion of them in its own DB.  How would it know a cache file from any other file?

I wouldn't be too concerned about what MC does under the covers.

[kewe65]

it doesn't really matter - i concur with lepa - for what purpose does MC add them to the library IF they have no business being there in the first place.

[MrC]

... for what purpose does MC add them to the library IF they have no business being there in the first place.

Curiously circuitous argument. :-)

The DB is how MC manages files.

[kewe65]

maybe my circuitousness wasn't clear...  :-)

The default Audio library and every single other custom Library has a specific use and its not as a storage mechanism for cache files.  If they are intended to be behind the scenes, then even as stack items is not a good use here. 

To say i shouldn't pay attention to the behind the scenes workings is fine but my library should not get inundated with them to boot. 

I see benefit in the files being created, but, again, how do I exclude them from being imported into all the libraries that are either there by default or created by me?

kevin