Discussion:
Unified cache for Misc
Robert Moser II
2002-02-23 00:27:20 UTC
Permalink
Well, it doesn't really matter except that every song in the database
(in memory and on disk) would have this duplicated information
if ($key eq "VOLUME") { $value = volume($path) }
elsif ($key eq "PATH") { $value = path($path) }
elsif ($key eq "FILE") { $value = file($path) }
elsif ($key eq "EXTENSION") { $value = extension($path) }
and not put duplicated information in the cache.
I'll probably go ahead and write the function both ways and see how much
uglier it is without the information in the cache.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Pinpoint the right security solution for your company - FREE
Guide from industry leader VeriSign gives you all the facts.
http://us.click.yahoo.com/lWSNbC/WdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2002-02-23 00:05:51 UTC
Permalink
VOLUME, PATH, FILE and EXTENSION are also missing, as they are easily
calculated from the path.
The main reason I put those in is for formatting the file info (proposal
soon to be posted).
Uh, but if you've got the path, why do you need to store them too?
Given the path key, you can get these without even hitting the cache.
Pretty much just to make the formatting implementation easier. The trick
is to match a value in the string (like VOLUME) then use that matched value
as the key of a hash lookup.
Well, it doesn't really matter except that every song in the database
(in memory and on disk) would have this duplicated information
stored. Probably just as easy to do:

if ($key eq "VOLUME") { $value = volume($path) }
elsif ($key eq "PATH") { $value = path($path) }
elsif ($key eq "FILE") { $value = file($path) }
elsif ($key eq "EXTENSION") { $value = extension($path) }

and not put duplicated information in the cache.

-dean


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
When building an e-commerce site, you want to start with a
secure foundation. Learn how with VeriSign's FREE Guide.
http://us.click.yahoo.com/kWSNbC/XdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2003-02-22 12:55:35 UTC
Permalink
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Unified cache for
Misc</title></head><body> <blockquote type="cite" cite>&gt; &gt;&nbsp; &gt;VOLUME, PATH, FILE
and EXTENSION are also missing, as they are easily<br>
&gt; &gt;&gt;calculated from the path.<br>
&gt; &gt;<br>
&gt; &gt;The main reason I put those in is for formatting the file
info (proposal<br>
&gt; &gt;soon to be posted).<br>
&gt;<br>
&gt;Uh, but if you've got the path, why do you need to store them
too?<br>
&gt;Given the path key, you can get these without even hitting the
cache.<br>
<br>
Pretty much just to make the formatting implementation easier.&nbsp;
The trick <br>
is to match a value in the string (like VOLUME) then use that matched
value </blockquote>
<blockquote type="cite" cite>as the key of a hash lookup.</blockquote>
<div><br></div>
<div>Well, it doesn't really matter except that every song in the
database (in memory and on disk) would have this duplicated
information stored.&nbsp; Probably just as easy to do:</div>
<div><br></div>
<div>if ($key eq &quot;VOLUME&quot;) { $value = volume($path) }</div>
<div>elsif ($key eq &quot;PATH&quot;) { $value = path($path) }</div>
<div>elsif ($key eq &quot;FILE&quot;) { $value = file($path) }</div>
<div>elsif ($key eq &quot;EXTENSION&quot;) { $value = extension($path)
}</div>
<div><br></div>
<div>and not put duplicated information in the cache.</div>
<div><br></div>
<div>-dean</div>
<div><br></div>
</body>
</html>
Robert Moser II
2002-02-22 22:54:22 UTC
Permalink
VOLUME, PATH, FILE and EXTENSION are also missing, as they are easily
calculated from the path.
The main reason I put those in is for formatting the file info (proposal
soon to be posted).
Uh, but if you've got the path, why do you need to store them too?
Given the path key, you can get these without even hitting the cache.
Pretty much just to make the formatting implementation easier. The trick
is to match a value in the string (like VOLUME) then use that matched value
as the key of a hash lookup.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Do you need to encrypt all your online transactions? Find
the perfect solution in this FREE Guide from VeriSign.
http://us.click.yahoo.com/vCuuSA/UdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2002-02-22 22:39:30 UTC
Permalink
Whoops, I'm just about to check in a unified cache!
Essentially it's what you proposed, but rather than the NOGENRE,
MP3TAG and MP3INFO that information is figured out with some logic
from the other existing fields.
How complicated is the logic? Especially compared to
exists($infoCache{$file}{'MP3TAG'})?
Not really, there's an assumption that if there's a TITLE tag then
we've got all the ID3, MP3INFO and fileLength information. But if
you think it's important, by all means fix it. We now read all those
things in at the same time, if possible. This helps keep all the
access to file meta information happening at one time.
VOLUME, PATH, FILE and EXTENSION are also missing, as they are easily
calculated from the path.
The main reason I put those in is for formatting the file info (proposal
soon to be posted).
Uh, but if you've got the path, why do you need to store them too?
Given the path key, you can get these without even hitting the cache.

-dean


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Do you need to encrypt all your online transactions? Find
the perfect solution in this FREE Guide from VeriSign.
http://us.click.yahoo.com/jWSNbC/UdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Robert Moser II
2002-02-22 22:31:16 UTC
Permalink
Whoops, I'm just about to check in a unified cache!
Essentially it's what you proposed, but rather than the NOGENRE,
MP3TAG and MP3INFO that information is figured out with some logic
from the other existing fields.
How complicated is the logic? Especially compared to
exists($infoCache{$file}{'MP3TAG'})?
VOLUME, PATH, FILE and EXTENSION are also missing, as they are easily
calculated from the path.
The main reason I put those in is for formatting the file info (proposal
soon to be posted).


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2003-02-22 12:55:43 UTC
Permalink
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Unified cache for
Misc</title></head><body>
<blockquote type="cite" cite>At 02:15 PM 2/22/02 -0800, you wrote:<br>
&gt;Whoops, I'm just about to check in a unified cache!<br>
&gt;<br>
&gt;Essentially it's what you proposed, but rather than the
NOGENRE,<br>
&gt;MP3TAG and MP3INFO that information is figured out with some
logic<br>
&gt;from the other existing fields.<br>
<br>
How complicated is the logic?&nbsp; Especially compared to <br>
exists($infoCache{$file}{'MP3TAG'})?</blockquote>
<div><br></div>
<div>Not really, there's an assumption that if there's a TITLE tag
then we've got all the ID3, MP3INFO and fileLength information.&nbsp;
But if you think it's important, by all means fix it.&nbsp; We now
read all those things in at the same time, if possible.&nbsp; This
helps keep all the access to file meta information happening at one
time.</div> <div><br></div> <blockquote type="cite" cite>&gt;VOLUME, PATH, FILE and EXTENSION are
also missing, as they are easily<br>
&gt;calculated from the path.<br>
<br>
The main reason I put those in is for formatting the file info
(proposal <br>
soon to be posted).</blockquote>
<div><br></div>
<div>Uh, but if you've got the path, why do you need to store them
too?&nbsp; Given the path key, you can get these without even hitting
the cache.</div>
<div><br></div>
<div>-dean</div>
<div><br></div>
</body>
</html>
dean blackketter
2002-02-22 22:15:53 UTC
Permalink
Whoops, I'm just about to check in a unified cache!

Essentially it's what you proposed, but rather than the NOGENRE,
MP3TAG and MP3INFO that information is figured out with some logic
from the other existing fields.

VOLUME, PATH, FILE and EXTENSION are also missing, as they are easily
calculated from the path.

Here are my comments, I'm doing a little testing before I commit:

Cleanup of Misc.pm.

All of our song/playlist/directory information is now in a single cache,
called simply the infoCache, which should save us some memory.

The infoCache is attached to the DB archive, when turned on.

When the DB is turned off, we don't populate it anymore, which should save
considerable memory.
This is a proposal to replace the following hashes with one unified hash.
%contentTypeCache
%fileLengthCache
%mp3infoCache
%mp3tagCache
Comments are welcome from everyone. We could probably even roll the
playlistCache and playlistAgeCache from Scan.pm into this, but we would
probably want to exclude them from being persisted.
It would be a hash of hashes like the mp3info and mp3tag are currently.
The primary key would be the absolute path (just like it currently is) and
it would have the following subkeys (with explanations) The subkeys are
literal strings and are not necessarily present for each file.
TYPE (corresponds to entry in contentTypeCache)
NOGENRE (exists if cache entry should not be used in genre cache, separate
from TYPE so that remote streamed mp3's can be excluded from genre cache)
MP3TAG (exists if mp3tag info has been extracted for file or if it should
not be extracted)
TITLE (from mp3tag or extensionless filename for playlists and shortcuts,
or name of directory)
ARTIST (from mp3tag)
ALBUM (from mp3tag)
GENRE (from mp3tag)
YEAR (from mp3tag)
COMMENT (from mp3tag)
TRACKNUM (from mp3tag)
MP3INFO (exists if mp3info has been extracted for file or if it should not
be extracted)
VERSION (from mp3info)
LAYER (from mp3info)
STEREO (from mp3info)
VBR (from mp3info)
BITRATE (from mp3info)
FREQUENCY (from mp3info)
SIZE (from mp3info)
SECS (from mp3info)
MM (from mp3info)
SS (from mp3info)
MS (from mp3info)
TIME (from mp3info)
COPYRIGHT (from mp3info)
PADDING (from mp3info)
MODE (from mp3info)
FRAMES (from mp3info)
FRAME_LENGTH (from mp3info)
VBR_SCALE (from mp3info)
VOLUME (volume portion of splitpath)
PATH (path portion of splitpath)
FILE (file portion of splitpath, without the file extension)
EXTENSION (file extension)
LENGTH (corresponds to entry in fileLengthCache)
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Pinpoint the right security solution for your company - FREE
Guide from industry leader VeriSign gives you all the facts.
http://us.click.yahoo.com/pCuuSA/WdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Robert Moser II
2002-02-22 22:03:10 UTC
Permalink
This is a proposal to replace the following hashes with one unified hash.
%contentTypeCache
%fileLengthCache
%mp3infoCache
%mp3tagCache

Comments are welcome from everyone. We could probably even roll the
playlistCache and playlistAgeCache from Scan.pm into this, but we would
probably want to exclude them from being persisted.

It would be a hash of hashes like the mp3info and mp3tag are currently.
The primary key would be the absolute path (just like it currently is) and
it would have the following subkeys (with explanations) The subkeys are
literal strings and are not necessarily present for each file.

TYPE (corresponds to entry in contentTypeCache)
NOGENRE (exists if cache entry should not be used in genre cache, separate
from TYPE so that remote streamed mp3's can be excluded from genre cache)

MP3TAG (exists if mp3tag info has been extracted for file or if it should
not be extracted)
TITLE (from mp3tag or extensionless filename for playlists and shortcuts,
or name of directory)
ARTIST (from mp3tag)
ALBUM (from mp3tag)
GENRE (from mp3tag)
YEAR (from mp3tag)
COMMENT (from mp3tag)
TRACKNUM (from mp3tag)

MP3INFO (exists if mp3info has been extracted for file or if it should not
be extracted)
VERSION (from mp3info)
LAYER (from mp3info)
STEREO (from mp3info)
VBR (from mp3info)
BITRATE (from mp3info)
FREQUENCY (from mp3info)
SIZE (from mp3info)
SECS (from mp3info)
MM (from mp3info)
SS (from mp3info)
MS (from mp3info)
TIME (from mp3info)
COPYRIGHT (from mp3info)
PADDING (from mp3info)
MODE (from mp3info)
FRAMES (from mp3info)
FRAME_LENGTH (from mp3info)
VBR_SCALE (from mp3info)

VOLUME (volume portion of splitpath)
PATH (path portion of splitpath)
FILE (file portion of splitpath, without the file extension)
EXTENSION (file extension)

LENGTH (corresponds to entry in fileLengthCache)


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Secure all your Web servers now - with a proven 5-part
strategy. The FREE Server Security Guide shows you how.
http://us.click.yahoo.com/iWSNbC/VdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2003-02-22 12:55:44 UTC
Permalink
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Unified cache for
Misc</title></head><body>
<div>Whoops, I'm just about to check in a unified cache!</div>
<div><br></div>
<div>Essentially it's what you proposed, but rather than the NOGENRE,
MP3TAG and MP3INFO that information is figured out with some logic
from the other existing fields.</div>
<div><br></div>
<div>VOLUME, PATH, FILE and EXTENSION are also missing, as they are
easily calculated from the path. </div>
<div><br></div>
<div>Here are my comments, I'm doing a little testing before I
commit:</div>
<div><br></div>
<div>Cleanup of Misc.pm.<br>
<br>
All of our song/playlist/directory information is now in a single
cache,<br>
called simply the infoCache, which should save us some memory.<br>
<br>
The infoCache is attached to the DB archive, when turned on.<br>
<br>
When the DB is turned off, we don't populate it anymore, which should
save&nbsp;&nbsp;&nbsp;&nbsp; <br>
considerable memory.<br>
</div>
<div><br></div>
<blockquote type="cite" cite>This is a proposal to replace the
following hashes with one unified hash.<br>
%contentTypeCache<br>
%fileLengthCache<br>
%mp3infoCache<br>
%mp3tagCache<br>
<br>
Comments are welcome from everyone.&nbsp; We could probably even roll
the <br>
playlistCache and playlistAgeCache from Scan.pm into this, but we
would <br>
probably want&nbsp; to exclude them from being persisted.<br>
<br>
It would be a hash of hashes like the mp3info and mp3tag are
currently.<br>
The primary key would be the absolute path (just like it currently is)
and <br>
it would have the following subkeys (with explanations)&nbsp; The
subkeys are <br>
literal strings and are not necessarily present for each file.<br>
<br>
TYPE (corresponds to entry in contentTypeCache)<br>
NOGENRE (exists if cache entry should not be used in genre cache,
separate <br>
from TYPE so that remote streamed mp3's can be excluded from genre
cache)<br>
<br>
MP3TAG&nbsp; (exists if mp3tag info has been extracted for file or if
it should <br>
not be extracted)<br>
TITLE (from mp3tag or extensionless filename for playlists and
shortcuts, <br>
or name of directory)<br>
ARTIST (from mp3tag)<br>
ALBUM (from mp3tag)<br>
GENRE (from mp3tag)<br>
YEAR (from mp3tag)<br>
COMMENT (from mp3tag)<br>
TRACKNUM (from mp3tag)<br>
<br>
MP3INFO (exists if mp3info has been extracted for file or if it should
not <br>
be extracted)<br>
VERSION (from mp3info)<br>
LAYER (from mp3info)<br>
STEREO (from mp3info)<br>
VBR (from mp3info)<br>
BITRATE (from mp3info)<br>
FREQUENCY (from mp3info)<br>
SIZE (from mp3info)<br>
SECS (from mp3info)<br>
MM (from mp3info)<br>
SS (from mp3info)<br>
MS (from mp3info)<br>
TIME (from mp3info)<br>
COPYRIGHT (from mp3info)<br>
PADDING (from mp3info)<br>
MODE (from mp3info)<br>
FRAMES (from mp3info)<br>
FRAME_LENGTH (from mp3info)<br>
VBR_SCALE (from mp3info)<br>
<br>
VOLUME (volume portion of splitpath)<br>
PATH (path portion of splitpath)<br>
FILE (file portion of splitpath, without the file extension)<br>
EXTENSION (file extension)<br>
<br>
LENGTH (corresponds to entry in fileLengthCache)<br>
<br>
<br>
------------------------ Yahoo! Groups Sponsor
---------------------~--&gt;<br>
Sponsored by VeriSign - The Value of Trust<br>
Secure all your Web servers now - with a proven 5-part<br>
strategy. The FREE Server Security Guide shows you how.<br>
http://us.click.yahoo.com/iWSNbC/VdiDAA/yigFAA/rIp0lB/TM<br>
---------------------------------------------------------------------<span </span>~-&gt;<br>
<br>
To unsubscribe from this group, send an email to:<br>
slimp3-dev-unsubscribe-***@public.gmane.org</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ </blockquote>
<div><br></div>
</body>
</html>

Loading...