PDA

View Full Version : iTunes / OSX / Mac Mini / Ripping = yikes



gocam
2005-04-26, 02:02
Perhaps I am expecting too much in which case please feel free to say so ! I'm a longtime happy slim owner - up until recently I've run the 5.4 server on a martian netdrive (low power linux box), but, for closer integration with itunes and my ipod etc, I've decided to experiment with putting the server on my new mac mini, where I also intended doing the ripping from within iTunes using blacktree's lame plugin. I have a slimp3 and a SB1. 6.x releases on my martian seemed to crash a lot when trying to open radio streams, so now seemed a good time to move across, and I also took opportunity to copy music from my 10/100-only accessible Martian to an external firewire drive.

So far so good - after remembering to open both ports on my mini's firewall (original slimp3 only needed 9000, hence much confusion on my part) and installing 6.0.2, setting iTunes to look to music I've placed on external firewire drive all works nicely. Live search is great ! (but doesn't work in Camino yet?)

OK - now I figured I'd test the end-to-end workflow, ripping a CD and observing it turning up in itunes and slim with no extra copying. And it works ! Yay. But, while ripping it basically seems impossible to do anything with my slims whatsoever. In fact, they both blackout and lose connection sporadically as the rip progresses, I _think_ coordinated with the write of file and tag info - is this simply because the itunes communication with the server is thrashing during the encode ? Is there anything I can do here ? Anyone in same boat ? I'd expected that if I was listening that the rip perhaps would go more slowly but that the server would still be able to serve with a reasonable 'nice' level but no can do it seems - moreover I even lose the displays completely.

This all makes me a little worried that my mini is not going to work out as a server if it's doing anything else which is a tad disturbing given that it's a 1.42GHz with a gig of memory and using external fast firewire drive.

Am I missing some way of optimising my setup and workflow? I'm also very curious about other mini owner's experiences of running the server - I'm almost contemplating sticking an old laptop on the network ONLY to act as a music server, to be honest....

Thanks for a great product, despite my grips above! and for all the superb support,
-g.

Craig, James (IT)
2005-04-26, 02:36
Have you changed the default iTunes library scan interval?
With it set to the default of 60s, SlimServer will be scanning the
iTunes library constantly while you are ripping.

James

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of gocam
Sent: 26 April 2005 10:03
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] iTunes / OSX / Mac Mini / Ripping = yikes


Perhaps I am expecting too much in which case please feel free to say so
! I'm a longtime happy slim owner - up until recently I've run the 5.4
server on a martian netdrive (low power linux box), but, for closer
integration with itunes and my ipod etc, I've decided to experiment
with putting the server on my new mac mini, where I also intended doing
the ripping from within iTunes using blacktree's lame plugin. I have a
slimp3 and a SB1. 6.x releases on my martian seemed to crash a lot when
trying to open radio streams, so now seemed a good time to move across,
and I also took opportunity to copy music from my 10/100-only
accessible Martian to an external firewire drive.

So far so good - after remembering to open both ports on my mini's
firewall (original slimp3 only needed 9000, hence much confusion on my
part) and installing 6.0.2, setting iTunes to look to music I've placed
on external firewire drive all works nicely. Live search is great ! (but
doesn't work in Camino yet?)

OK - now I figured I'd test the end-to-end workflow, ripping a CD and
observing it turning up in itunes and slim with no extra copying. And
it works ! Yay. But, while ripping it basically seems impossible to do
anything with my slims whatsoever. In fact, they both blackout and lose
connection sporadically as the rip progresses, I _think_ coordinated
with the write of file and tag info - is this simply because the itunes
communication with the server is thrashing during the encode ? Is there
anything I can do here ? Anyone in same boat ? I'd expected that if I
was listening that the rip perhaps would go more slowly but that the
server would still be able to serve with a reasonable 'nice' level but
no can do it seems - moreover I even lose the displays completely.

This all makes me a little worried that my mini is not going to work
out as a server if it's doing anything else which is a tad disturbing
given that it's a 1.42GHz with a gig of memory and using external fast
firewire drive.

Am I missing some way of optimising my setup and workflow? I'm also
very curious about other mini owner's experiences of running the server
- I'm almost contemplating sticking an old laptop on the network ONLY to
act as a music server, to be honest....

Thanks for a great product, despite my grips above! and for all the
superb support,
-g.


--
gocam

mcauter
2005-04-26, 03:55
sounds interesting, but how does one change the i-tunes scanning frequency? (might be obvious but I can not see how!)

Craig, James (IT)
2005-04-26, 04:02
Server Settings -> iTunes -> iTunes Reload interval

James

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of mcauter
Sent: 26 April 2005 11:56
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] Re: iTunes / OSX / Mac Mini / Ripping = yikes


sounds interesting, but how does one change the i-tunes scanning
frequency? (might be obvious but I can not see how!)
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

kdf
2005-04-26, 04:02
Quoting mcauter <mcauter.1o3e9z (AT) no-mx (DOT) forums.slimdevices.com>:

>
> sounds interesting, but how does one change the i-tunes scanning
> frequency? (might be obvious but I can not see how!)

server settings->itunes

itunes reload interval.

-kdf

gocam
2005-04-26, 10:36
I'll give that a try and thanks for suggestion - what would be really good is to have some way of specifying a bracket easily though - you know, something like a StartRip/EndRip button or such that would cause it not to try checking the library until I'm done, with me manually hitting that button to say so - or alternatively, don't do a complete recheck until the size of the main folder has stabilised for a certain duration ? (maybe that's what the setting does?)

Actually - I'm curious now - doesn't the perl script simply check the iTunes cached file tables for changes, or is it plowing through all the subfiles on the disk ? Can I make it do just the former if it's doing the latter ?

Thanks for suggestion though - I'll try tonight.
-g.

gocam
2005-04-26, 16:28
Another thought - on the mac platform, wouldn't it be possible to listen for applescript notices/events or something to know when itunes is in process of ripping or itunes-LAME is doing it's thing, and suspend any synchronization until the end of the process ?

Craig, James (IT)
2005-04-27, 02:07
> or alternatively, don't do a complete
>recheck until the size of the main folder has stabilised for a certain
>duration ? (maybe that's what the setting does?)

No, the scan just checks for the modified time changing on the XML file.

This seems like a really sensible suggestion as the user's iTunes
activity is likely to come in bursts when adding tracks or modifying
tags. I'd suggest opening this as an enhancement request...

>Actually - I'm curious now - doesn't the perl script simply check the
>iTunes cached file tables for changes, or is it plowing through all the
>subfiles on the disk ? Can I make it do just the former if it's doing
>the latter ?

The scan checks the iTunes XML file.
As I understand it, any new tracks are added to the database and the
file scanned for tag info
(the XML does not contain all the tags SlimServer requires - which ones
are missing I wonder?)
If a track is already in the database it is ignored unless the file
modified time has changed.
This is actually pretty quick if 99% of your library has not changed.

What I find kills SlimServer performance is scanning of the playlists -
I have a number of thousand+ track playlists and when they are scanned
is when I lose connectivity.
One enhancement already suggested is reading only selected playlists
from the XML.

>Another thought - on the mac platform, wouldn't it be possible to
listen
>for applescript notices/events or something to know when itunes is in
>process of ripping or itunes-LAME is doing it's thing, and suspend any
>synchronization until the end of the process ?

The Slim developers like all the core functionality to be cross platform
so I doubt that would be favoured.

James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

dean
2005-04-27, 09:01
That's not exactly true. With the default setting, SlimServer will
wait a minimum of 60 seconds after ending an import of your iTunes
library before starting a new one. If your library is very large and
you are ripping for a long time, you may see that the iTunes importing
is running most of the time.

You can adjust the delay in the server settings to make it wait longer,
but the downside is that YOU have to wait longer to see new songs in
your library.

-dean



On Apr 26, 2005, at 2:36 AM, Craig, James (IT) wrote:

> Have you changed the default iTunes library scan interval?
> With it set to the default of 60s, SlimServer will be scanning the
> iTunes library constantly while you are ripping.
>
> James
>
> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of gocam
> Sent: 26 April 2005 10:03
> To: discuss (AT) lists (DOT) slimdevices.com
> Subject: [slim] iTunes / OSX / Mac Mini / Ripping = yikes
>
>
> Perhaps I am expecting too much in which case please feel free to say
> so
> ! I'm a longtime happy slim owner - up until recently I've run the 5.4
> server on a martian netdrive (low power linux box), but, for closer
> integration with itunes and my ipod etc, I've decided to experiment
> with putting the server on my new mac mini, where I also intended doing
> the ripping from within iTunes using blacktree's lame plugin. I have a
> slimp3 and a SB1. 6.x releases on my martian seemed to crash a lot when
> trying to open radio streams, so now seemed a good time to move across,
> and I also took opportunity to copy music from my 10/100-only
> accessible Martian to an external firewire drive.
>
> So far so good - after remembering to open both ports on my mini's
> firewall (original slimp3 only needed 9000, hence much confusion on my
> part) and installing 6.0.2, setting iTunes to look to music I've placed
> on external firewire drive all works nicely. Live search is great !
> (but
> doesn't work in Camino yet?)
>
> OK - now I figured I'd test the end-to-end workflow, ripping a CD and
> observing it turning up in itunes and slim with no extra copying. And
> it works ! Yay. But, while ripping it basically seems impossible to do
> anything with my slims whatsoever. In fact, they both blackout and lose
> connection sporadically as the rip progresses, I _think_ coordinated
> with the write of file and tag info - is this simply because the itunes
> communication with the server is thrashing during the encode ? Is there
> anything I can do here ? Anyone in same boat ? I'd expected that if I
> was listening that the rip perhaps would go more slowly but that the
> server would still be able to serve with a reasonable 'nice' level but
> no can do it seems - moreover I even lose the displays completely.
>
> This all makes me a little worried that my mini is not going to work
> out as a server if it's doing anything else which is a tad disturbing
> given that it's a 1.42GHz with a gig of memory and using external fast
> firewire drive.
>
> Am I missing some way of optimising my setup and workflow? I'm also
> very curious about other mini owner's experiences of running the server
> - I'm almost contemplating sticking an old laptop on the network ONLY
> to
> act as a music server, to be honest....
>
> Thanks for a great product, despite my grips above! and for all the
> superb support,
> -g.
>
>
> --
> gocam
>

Steven Moore
2005-04-27, 09:34
I think some of us are setting the reload interval very high (1000000)
and rescanning manually once we have finished importing our songs in
itunes.

Steven Moore
On 27 Apr 2005, at 5:01 pm, dean blackketter wrote:

> That's not exactly true. With the default setting, SlimServer will
> wait a minimum of 60 seconds after ending an import of your iTunes
> library before starting a new one. If your library is very large and
> you are ripping for a long time, you may see that the iTunes importing
> is running most of the time.
>
> You can adjust the delay in the server settings to make it wait
> longer, but the downside is that YOU have to wait longer to see new
> songs in your library.
>
> -dean
>
>
>
> On Apr 26, 2005, at 2:36 AM, Craig, James (IT) wrote:
>
>> Have you changed the default iTunes library scan interval?
>> With it set to the default of 60s, SlimServer will be scanning the
>> iTunes library constantly while you are ripping.
>>
>> James
>>
>> -----Original Message-----
>> From: discuss-bounces (AT) lists (DOT) slimdevices.com
>> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of gocam
>> Sent: 26 April 2005 10:03
>> To: discuss (AT) lists (DOT) slimdevices.com
>> Subject: [slim] iTunes / OSX / Mac Mini / Ripping = yikes
>>
>>
>> Perhaps I am expecting too much in which case please feel free to say
>> so
>> ! I'm a longtime happy slim owner - up until recently I've run the 5.4
>> server on a martian netdrive (low power linux box), but, for closer
>> integration with itunes and my ipod etc, I've decided to experiment
>> with putting the server on my new mac mini, where I also intended
>> doing
>> the ripping from within iTunes using blacktree's lame plugin. I have a
>> slimp3 and a SB1. 6.x releases on my martian seemed to crash a lot
>> when
>> trying to open radio streams, so now seemed a good time to move
>> across,
>> and I also took opportunity to copy music from my 10/100-only
>> accessible Martian to an external firewire drive.
>>
>> So far so good - after remembering to open both ports on my mini's
>> firewall (original slimp3 only needed 9000, hence much confusion on my
>> part) and installing 6.0.2, setting iTunes to look to music I've
>> placed
>> on external firewire drive all works nicely. Live search is great !
>> (but
>> doesn't work in Camino yet?)
>>
>> OK - now I figured I'd test the end-to-end workflow, ripping a CD and
>> observing it turning up in itunes and slim with no extra copying. And
>> it works ! Yay. But, while ripping it basically seems impossible to do
>> anything with my slims whatsoever. In fact, they both blackout and
>> lose
>> connection sporadically as the rip progresses, I _think_ coordinated
>> with the write of file and tag info - is this simply because the
>> itunes
>> communication with the server is thrashing during the encode ? Is
>> there
>> anything I can do here ? Anyone in same boat ? I'd expected that if I
>> was listening that the rip perhaps would go more slowly but that the
>> server would still be able to serve with a reasonable 'nice' level but
>> no can do it seems - moreover I even lose the displays completely.
>>
>> This all makes me a little worried that my mini is not going to work
>> out as a server if it's doing anything else which is a tad disturbing
>> given that it's a 1.42GHz with a gig of memory and using external fast
>> firewire drive.
>>
>> Am I missing some way of optimising my setup and workflow? I'm also
>> very curious about other mini owner's experiences of running the
>> server
>> - I'm almost contemplating sticking an old laptop on the network ONLY
>> to
>> act as a music server, to be honest....
>>
>> Thanks for a great product, despite my grips above! and for all the
>> superb support,
>> -g.
>>
>>
>> --
>> gocam
>>

Craig, James (IT)
2005-04-27, 09:39
Indeed.
BTW KDF changed the iTunes scan for 6.1 - setting the interval to 0
should now disable the automated scans.

James

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Steven Moore
Sent: 27 April 2005 17:34
To: Slim Devices Discussion
Subject: Re: [slim] iTunes / OSX / Mac Mini / Ripping = yikes

I think some of us are setting the reload interval very high (1000000)
and rescanning manually once we have finished importing our songs in
itunes.

Steven Moore
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

Steven Moore
2005-04-27, 10:45
Great news.

Steven Moore
On 27 Apr 2005, at 5:39 pm, Craig, James (IT) wrote:

> Indeed.
> BTW KDF changed the iTunes scan for 6.1 - setting the interval to 0
> should now disable the automated scans.
>
> James
>
> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Steven
> Moore
> Sent: 27 April 2005 17:34
> To: Slim Devices Discussion
> Subject: Re: [slim] iTunes / OSX / Mac Mini / Ripping = yikes
>
> I think some of us are setting the reload interval very high (1000000)
> and rescanning manually once we have finished importing our songs in
> itunes.
>
> Steven Moore
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender.
> Sender does not waive confidentiality or privilege, and use is
> prohibited.
>
>