List of Audio and Video files disapear when an MD used

[Techstyle]

I have a Hybrid Core with 3 HDD's:

200 Gb IDE drive with the OS on it and a small amount of media
450 GB SATA drive with 200 GB of Video on it
1 TB SATA drive with 770 Gb of Video and Audio on it

with the core alone working, all media is visible on the orbiters.

If I boot up any one of my two MD's (a Dell D620 with Gigabit Broadcom NIC or an Athlon XP 2600 desktop machine with 100 Mbit NIC) and then access some of the media, after an amount of time the list of media changes and only a few files are visible, some on the 200 GB drive and one or two on the 1TB machine (Thom's 'using media in LinuxMCE' weirdly and an REM album).  After this I have to reboot to get it back.  before the reboot I can go into the KDE desktop and use dolphin and access the media from there on the core.

Any ideas why this is happening and what I can do to get around it?

[totallymaxed]

I have a Hybrid Core with 3 HDD's:

200 Gb IDE drive with the OS on it and a small amount of media
450 GB SATA drive with 200 GB of Video on it
1 TB SATA drive with 770 Gb of Video and Audio on it

with the core alone working, all media is visible on the orbiters.

If I boot up any one of my two MD's (a Dell D620 with Gigabit Broadcom NIC or an Athlon XP 2600 desktop machine with 100 Mbit NIC) and then access some of the media, after an amount of time the list of media changes and only a few files are visible, some on the 200 GB drive and one or two on the 1TB machine (Thom's 'using media in LinuxMCE' weirdly and an REM album).  After this I have to reboot to get it back.  before the reboot I can go into the KDE desktop and use dolphin and access the media from there on the core.

Any ideas why this is happening and what I can do to get around it?

Sounds like this is the long standing problem with the StorageRadar scripts... it typically affects systems with multiple data drives added to the Core and or cifs shares.

We use a pretty ugly temporary fix for this currently that forces the drives to remain mounted using a screen session;

open an ssh session on your Core and start a screen session... then cd to /home/public/data/videos/<symlink to 1st of your data drives>

so this goes something like this;

- ssh into your Core

Use the screen command;

Code: [Select]

screen -S keep_drives_mounted<return>


**The string after the '-S' switch above can be anything you desire... its just to make identifying the screen session easier ;-)

Code: [Select]

cd /home/public/data/videos/<symlink to 1st of your data drives> <return>


Now open a new window with "Ctrl-A" "c"; ***That is hold Ctrl down and press 'a' once...then with no other keys depressed...press 'c' once ***

and 'cd' as above but this time into your next drive.

Now open a new window with "Ctrl-A" "c"

and 'cd' as above but this time into your last drive.

Now you can switch to each window to check they are all there with "Ctrl-A "n" which will cycle through each screen window each time you do it.

Now you need to detach from the window using "Ctrl-A" "d". This will drop you back into your shell. All screen windows you created are still there and you can re-attach to them later at anytime by doing the following to list all your screen sessions;

Code: [Select]

screen -ls <return>


You should see something like below;

Code: [Select]

demo@DCErouter:~$ screen -ls
There is a screen on:
        13022.keep_drives_mounted       (15/03/09 12:44:25)     (Detached)
1 Socket in /var/run/screen/S-tracy.

demo@DCErouter:~$


Now you can see the screen session called '13022.keep_drives_mounted' listed as 'detached' ... so we use the following command to re-attach to your screen session;

Code: [Select]

screen -r 13022.keep_drives_mounted<return>


Normally once you have set this screen session up you should never need to go back to it. If you reboot your Core then all of the above screen sessions will be lost and you will have to re-do the steps above again... or create a script that runs during boot up to do it for you.

The above procedure is a 'hack' and hopefully this problem will be resolved properly in the StorageRadar scripts for 810.

All the best

Andrew

[Techstyle]

Thanks Andrew, as you may know my Linux skills are severely lacking.

I opened a konsole window and typed 'ssh linuxmce@dcerouter'

typed in the root password

typed the command 'session -S keep_drives_mounted'

I recieved an error message of no such command or something like that

I typed 'cd /home/public/data/videos' because I didn't know what the drive was called

am I going in the right direction so far?

[colinjones]

The command is:

screen

not

session

[Techstyle]

Not only are my Linux skills lacking but I can't read either, Thanks Collin

I will let you know how I get on

[Techstyle]

that seems to have worked - Thanks Andrew!!

I have been banging my head agaist the wall with that one for sometime.

I will have to make a script that runs at boot, any pointers on how to go about that?

[donpaul]

You can put the command in /etc/rc.local

or

You can create your own script and put it in /etc/rc.d and give it execute perms with:
# chmod +x scriptname

Then configure it to run at boot with:
# update-rc.d scriptname defaults

[totallymaxed]

You can put the command in /etc/rc.local

or

You can create your own script and put it in /etc/rc.d and give it execute perms with:
# chmod +x scriptname

Then configure it to run at boot with:
# update-rc.d scriptname defaults

Yep that would do it ;-)

Andrew

[Techstyle]

So, (remember I am new to Linux)

I was trying to get my head around how this works.

I think I have got it but correct me if I am wrong:

The 'screen' command allows you to remotely log in to the core.  I open a session on each of the drives so that these drives cannot unmount because they are in use.

This probably means I don't have to cd into the ..../Audio as well as the ..../Video directory of each drive, is that correct?

I am looking at writing this script but I have read some articles that say I would have to enter the root password manually, is there a way to add it to the script or not need it?

Thanks
Jason
 

[colinjones]

Basically, correct. The 'screen' command can be thought of as a virtual console session, like starting a normal console session, but which can subsequently be 'disconnected' from the physical console so that what ever command(s)/script is initiated in that screen session 'feels' like it is still attached to a real console session with all the normal standard input and outputs. Correct, you only need to cd into 1 folder on a drive device to ensure that the drive, with all its folders, remain mounted.

Its not clear to me what you are trying to run as root. I note you were doing ssh's to the core and trying to become root from there... why? You are trying to run the script on the core, so you don't need to ssh to itself again, and you don't need root permissions to do a cd. Really all you want to do is and a boot-time script that starts a screen session, then cd's to /home/public/data/audio/blahblah or /mnt/device/##/public/blah

[Techstyle]

OK, that makes sense.

When Andrew says 'ssh into the core' I was running it from a console session on the core so I didn't need to do 'ssh linuxmce@dcerouter'.  I didn't realize that at the time.

Anyway, would the script look something like this:

#!/bin/bash
screen -S keep_drives_mounted
cd /home/public/data/videos/[drive1]
Ctrl-a c
cd /home/public/data/videos/[drive2]
Ctrl-a c
cd /home/public/data/videos/[drive3]
Ctrl-a d
screen -r 13022.keep_drives_mounted

I will then save it as 'keep_drives_mounted.sh' (is that the corrrect extention) in /etc/rc.d

'chmod +x keep_drives_mounted.sh'

to make it executable, then

'update-rc.d keep_drives_mounted defaults'

Does this look OK?

Thanks,
Jason

[Techstyle]

That script doesn't seem to work

any suggestions?

[nite_man]

Have you manage to make it work? Maybe Andrew can share his script if it isn't a secret And again. To use that hack the names of the drives should be specified in the script if I understand clearly. So, what the difference between using LinuxMCE functionality to mount shares and mount them manually via fstab (make symlinks is not so big deal)?

[Techstyle]

The solution works perfectly and the drives are fully specified as they appear on the system.  Unfortunately my script doesn't work.

Every time I reboot I have to redo this.  I will be getting back to this soon and looking at some different scripts to check my syntax.

any help would be appreciated.

[totallymaxed]

Have you manage to make it work? Maybe Andrew can share his script if it isn't a secret And again. To use that hack the names of the drives should be specified in the script if I understand clearly. So, what the difference between using LinuxMCE functionality to mount shares and mount them manually via fstab (make symlinks is not so big deal)?

The script is just a replication of the steps you would use manually with the screen command...its certainly not a secret at all...I just have to find it ;-)

The problem with manually mounting drives in fstab is that the drive management scripts can get confused and it can create all manner of problems with lockups etc. Its a very bad idea to use manual fstab entries currently.

Andrew