Fetching 7.8 from Git and running on an SSD

[gharris999]

The following CPAN modules were found but cannot work with Logitech Media Server:
Audio::Scan (loaded 0.93 but missing object file, need 0.93)
Image::Scale (loaded 0.08 but missing object file, need 0.08)

My checkout of 7.8 includes both:

/usr/share/lms/server/CPAN/arch/5.14/MSWin32-x86-multi-thread/auto/Audio/Scan/Scan.dll

..and..

/usr/share/lms/server/CPAN/arch/5.14/MSWin32-x86-multi-thread/auto/Image/Scale/Scale.dll

Searching the binaries for version strings, I find:

Scan.c
0.93
v5.14.0

..and..

Scale.c
0.08
v5.14.0

So I think the right versions are in the right place in the repos. That said, I've made no attempt to run the git code from Windows yet. Please let us know what it takes to get it working once you figure it out.

[JJZolx]

Thanks for the help. When I run that command I end up with only a hidden .git subdirectory of about 88 MB and nothing else.

C:\>git clone -n --depth 1 https://github.com/Logitech/slimserver.git "D:\Git\Logitech Media Server"

Cloning into 'D:\Git\Logitech Media Server'...
remote: Counting objects: 4452, done.
remote: Compressing objects: 100% (2740/2740), done.
remote: Total 4452 (delta 514), reused 3579 (delta 351)
Receiving objects: 100% (4452/4452), 88.41 MiB | 737 KiB/s, done.
Resolving deltas: 100% (514/514), done.

So if I'm running and keeping both 7.7 and 7.8 up to date locally, then I would update the local repo from Logitech's, then update each of the branch version repos from my local repository, correct?

[gharris999]

Thanks for the help. When I run that command I end up with only a hidden .git subdirectory of about 88 MB and nothing else.

C:\>git clone -n --depth 1 https://github.com/Logitech/slimserver.git "D:\Git\Logitech Media Server"

Cloning into 'D:\Git\Logitech Media Server'...
remote: Counting objects: 4452, done.
remote: Compressing objects: 100% (2740/2740), done.
remote: Total 4452 (delta 514), reused 3579 (delta 351)
Receiving objects: 100% (4452/4452), 88.41 MiB | 737 KiB/s, done.
Resolving deltas: 100% (514/514), done.

So if I'm running and keeping both 7.7 and 7.8 up to date locally, then I would update the local repo from Logitech's, then update each of the branch version repos from my local repository, correct?

I think in terms of the git mindset, there aren't "branch version repos"...there's just the local repo and when you check out a branch, the code resides in the same directory tree as the local repo.

Anyway, once you clone the repo, you need to check out a branch. I.e.

cd "D:\Git\Logitech Media Server"
git checkout "7.8"

To check the status of your repo/branch, try these commands:

cd "D:\Git\Logitech Media Server"
git remote show origin
git branch -r
git status

When you update the local repo via a 'git pull' (same as a svn up), you may want to clean the local repo first, discarding any local changes you might have made:

cd "D:\Git\Logitech Media Server"
git reset --hard
git clean -fd

Then update the repo:

cd "D:\Git\Logitech Media Server"
git pull

That will update ALL the branches. Of course, only 7.7 and 7.8 are likely to have had any commits so they're the ones where you'll see activity.

[JJZolx]

To run both 7.7 and 7.8, that means I need to do two clones, and checkout 7.7 in one and 7.8 in the other, correct?

[gharris999]

To run both 7.7 and 7.8, that means I need to do two clones, and checkout 7.7 in one and 7.8 in the other, correct?

Yes, you could do that, but it's not necessary. It literally only takes a few seconds to switch a 7.8 branch checkout to 7.7. And I don't think there are any prefs or database differences, so you could potentially share prefs and data between the branches.

Or, you can do as I do, and keep separate cache & prefs dirs for each checked out version that you run.

You could write a switch-branch batch file to accomplish this with minimal effort. That's what I do on linux...I have a shell script that automates all the housekeeping that I do when I switch branches.

For my purposes, to make sure that my plugins still run with legacy squeezecenter code, I checked out 7.3.4 and then copied the whole directory tree and then deleted the .git dir in the new (static) 7.3.4 folder. (Then I spent a lot of time getting 7.3.4 to run with perl 5.14.2, but that's another matter). But anyway, that's another approach: if you have a branch that you know won't see any more updates, then check it out and then "orphan" it from the git repo.

[Philip Meyer]

>So I think the right versions are in the right place in the repos. That
>said, I've made no attempt to run the git code from Windows yet. Please
>let us know what it takes to get it working once you figure it out.
>
I don't really want to pull down all branches, and copious copies of the binaries for each OS onto my SSD. I can mess about with junction points, and clone the repository to only pull back 1 level deep in each branch. Perhaps it's also possible to set up a list of folders to ignore, such that it won't clone certain parts of the repository.

I currently have several different local folders containing different branches that I run SBS/LMS from. At the moment, two of them are SBS and came from SVN, and only one is from Git. I have different prefs, logs and cache folders for each. I also checkout my plugins into the server/Plugins folder from my own SVN repository. It is much more preferable to have separate folders to run each version from rather than switching branches, esp. when running on an SSD, where I want to reduce writes and maximise reads.

Perhaps it would work better by having one local git repository in a staging area. Checkout a particular branch, and then export the content to a separate folder for running.

I'm considering giving up with running the code via Git checkout. As there's hardly any changes being checked in, it's perhaps more beneficial to download a nightly occasionally. I can check the git repostory on the web to detect when there's something significant to require a new nightly download. I can keep exported checked out copies to testing my plugins against older releases.

[JJZolx]

Yes, you could do that, but it's not necessary. It literally only takes a few seconds to switch a 7.8 branch checkout to 7.7. And I don't think there are any prefs or database differences, so you could potentially share prefs and data between the branches.

Or, you can do as I do, and keep separate cache & prefs dirs for each checked out version that you run.

You could write a switch-branch batch file to accomplish this with minimal effort. That's what I do on linux...I have a shell script that automates all the housekeeping that I do when I switch branches.

Ok, but I want to run them at the same time (as well as 7.6 and 7.5, but I can run them from their old SVN checkouts, if necessary). Is that possible from one clone? I don't care if it's 901 MB in size. I already do keep separate cache, prefs and log directories for each instance of the server that I run. Can the checkouts be to different locations, or is that not the way it's done?

I'm still unclear about what is actually being pulled down when cloning.

- 'git clone -n --depth 1' is 88 MB
- 'git clone' is 901 MB
- you mention 252 MB

[gharris999]

Ok, but I want to run them at the same time (as well as 7.6 and 7.5, but I can run them from their old SVN checkouts, if necessary). Is that possible from one clone?

I assume you're not talking about running simultaneous instances of LMS/SBS on the same machine -- which, if you are, would require some pretty fancy footwork as far as I know.

This is how I switch from 7.7 to 7.8 on my headless Ubuntu server 12.04 regular 'production' server: I ssh into the server from my windows box and issue the single command:

# sudo service lms switch-branch '7.8'

Within 30 seconds, lms 7.7 has stopped, 7.8 has been checked out, the script has updated several symbolic directory links, restarted the lms service and I have branch 7.8 up and running and playing music. One command and 30 seconds -- that's all there is to it. I'm more than happy to share my service control script and I'm very confident you can accomplish exactly the same thing on windows with a batch file run as administrator. You could create shortcuts to the batch file so switching branches is as simple as a double-click with the mouse.

Or check out a branch and then copy it to a separate location. Either method works.

With my setup, I have a cron job that updates the local repo (and thus, ALL the branches) weekly. It fired off automatically last night, performed a 'git pull' and made this change:

[12-07-31 02:05:10.4637] spc-update.sh (23558) git pull /usr/share/lms/server
Updating ff5bb05..2f11d0a
Fast-forward
 Slim/Player/Squeezebox2.pm |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

That pulled in the changes Andy made 4 days ago to fix MOG playback halts in Australia, apparently. I could easily adjust my cron job so that it 'git pull'ed daily rather than weekly. But with the current pace of change in the code, weekly seems more than sufficient.

So, I do think there are benefits to just having a single local repo with (by implication) a single branch checked out at any given time: the house keeping is a lot simpler.

I don't care if it's 901 MB in size. I already do keep separate cache, prefs and log directories for each instance of the server that I run. Can the checkouts be to different locations, or is that not the way it's done?

I'm still unclear about what is actually being pulled down when cloning.

- 'git clone -n --depth 1' is 88 MB
- 'git clone' is 901 MB
- you mention 252 MB

I cloned the git repository back in May and at that time, a --depth 1 clone yielded a local repo with a .git directory tree of about 252mb. I don't know if anything has changed in the mean time that would alter that. I wouldn't think so. To be on the safe side, I would suggest re-cloning the repo but, this time, make the destination a path that doesn't include any spaces. I.e. something like D:\LMSRepo\server.

My whole LMS directory tree, including the 7.8 checked out branch and the .git directory weighs in at 584mb.

[gharris999]

>So I think the right versions are in the right place in the repos. That
>said, I've made no attempt to run the git code from Windows yet. Please
>let us know what it takes to get it working once you figure it out.
>
I don't really want to pull down all branches, and copious copies of the binaries for each OS onto my SSD. I can mess about with junction points, and clone the repository to only pull back 1 level deep in each branch. Perhaps it's also possible to set up a list of folders to ignore, such that it won't clone certain parts of the repository.

My total experience with git is *just enough* to make it work for me. Everything you suggest here may be possible, but I don't really know off hand.

In terms of wear on your SSD, I asked the same question back in February when I set my current server up with a SSD OS/boot drive. See:

http://forums.slimdevices.com/showth...ion&highlight=

So far, I've noticed no performance degradation at all and, despite swapping LMS branches in and out, I'm fairly confident that this SSD will outlive me.

[JJZolx]

I assume you're not talking about running simultaneous instances of LMS/SBS on the same machine -- which, if you are, would require some pretty footwork as far as I know.

No, that's exactly what I'm talking about - simultaneous instances. I've run as many as 10 or 12 instances on my server simultaneously with the SVN checkouts. I can run as many instances as I like from any one of the checkouts.

So it looks like I'll need either multiple clones, each containing a different version, or else I'll need to script updates to fetch, do a checkout of a different version, then copy that version to its final location and repeat for each version. I could use a directory sync tool like robocopy to minimize the copying to only updated files.