slow loading

[oxonian]

The NMT box seems slow at loading. This takes 15 minutes, and I gather its from changing the permissions on ALL of the files on the HD. My hard-drive contains a lot of documents, videos, music files and so takes a long time.

Ive looked at /etc/init_nmt and shows
chmod 777 $SHAREROOT -R
and
chown -R nmt:nmt $SHAREROOT

This seems to be trigged when the permissions or user owner is incorrect. That's fine, but why does it continue to do it each time ? Does this script have bugs,, can 'ls' see 'nmt' or should it detect 501, also why does it do it 5 times the the WHOLE hard-drive. why not just do it in /share/Video, Music, and so on.. so my additional folders /share/home/me/... is ignored.

I understand this is to allow NMT player full access to the HD, but it makes things a lot slower.

Oxonian

[oxonian]

Is there nobody that studies or develops for the NMT device that has ideas about this ?

I cant find any bootup logs or messages to show what the box is actually doing while loading...

Oxonian

[dc11ab]

Don't think there's anything useful in /var/logs or so but you could try demsg to see if the problem is already at that stage.

I assume you have a rather large drive. Mind sharing brand/model?

Good findings, by the way.

[azulmania]

I have the same trouble.
First when my HDD was empty didn't matter but it seems while my amount of files is increasing that means more time to wait for loading when I turn on NMT...
I want to use my NMT as media center and network storage drive for all my files...
Is there a workarround for making it faster at loading?, partitioning or something else?
My HDD is 1.5TB

Regards.

[journey4712]

the init_nmt script is stored in system flash where as users we cant edit the file(not in persistant way at least), and there is no way as a user to inject into the boot process before this script is run.

Its unfortunate, but it seems unless syabas are interested in changing this(likely not, as its a quick hack to ignore file permissions so they didn't have to fix bugs in other programs they just suggest a reboot) we are all stuck as is.

journey471

[laureck]

(07-30-2009 02:52 PM)oxonian Wrote:  The NMT box seems slow at loading. This takes 15 minutes, and I gather its from changing the permissions on ALL of the files on the HD. My hard-drive contains a lot of documents, videos, music files and so takes a long time.

Ive looked at /etc/init_nmt and shows
chmod 777 $SHAREROOT -R
and
chown -R nmt:nmt $SHAREROOT

This seems to be trigged when the permissions or user owner is incorrect. That's fine, but why does it continue to do it each time ? Does this script have bugs,, can 'ls' see 'nmt' or should it detect 501, also why does it do it 5 times the the WHOLE hard-drive. why not just do it in /share/Video, Music, and so on.. so my additional folders /share/home/me/... is ignored.

I'm a little late on this one but I currently have the same lengthy bootup issue.
This is a nice finding you made here but I'm not sure if this could be the reason why bootup is so slow. As you said, both recursive chown and chmod are bound to initial tests:

Code:

CHECKMODE="`ls -ld $SHAREROOT | grep drwxrwxrwx`"
        if test -z $CHECKMODE
        then
                echo "Do chmod on $SHAREROOT ..."
                chmod 777 $SHAREROOT -R
        fi

CHECKMODE="`ls -ld $SHAREROOT | grep root`"
        if test -n "$CHECKMODE"
        then
        echo "Do chown on HDD..."
                chown -R nmt:nmt $SHAREROOT
        fi

in both cases, the condition is wrong and the lengthy chown / chmod are not run.
I tried to launch the script by hand through telnet and it does not launch lengthy operations...

<update>
Actually I sort of demonstrated that I'm wrong: chmod does not seem to be an issue but chown seems to get executed at each reboot.
As I understand the script above (2nd part) chown -R nmt:nmt should be executed if (and only if) $SHAREROOT (the internal hard drive) belongs to root. In this case a chown is needed to allow gaya to browse it.

To test this, I created a file as root in a subdirectory :

Code:

/opt/sybhttpd/localhost.drives/HARD_DISK # touch bin/mytest
/opt/sybhttpd/localhost.drives/HARD_DISK # ls -l bin
-rw-r--r--    1 root     root            0 Nov  3 10:26 mytest

As you can see, mytest belongs to root and has permissions 644.
Then I rebooted the pch.
After the lengthy boot, I telneted to it and checked the file mode and owner :

Code:

/opt/sybhttpd/localhost.drives/HARD_DISK/bin # ls -l
-rw-r--r--    1 nmt      nmt             0 Nov  3 10:26 mytest

As you can see now, permissions were not changed but mytest now belongs to nmt.
This file is in a subdirectory of $SHAREROOT so it must have been changed with a recursive chown, hence the long bootup time.

I'll submit a bug when I can find the reason why this chown is triggered
</update>