umount through UI?

[CharlieSummers]

While I'm using a USB SATA dock for large hard drives, this should have relevance to any USB device. I have suffered a pretty consistent series of lost files, 0-byte files, and other file system anomalies on drives which I can only assume are caused either by the lack of proper unmounting or by the internal copy/move functions - can't really tell without further errors, something I'd really like to avoid. Some have been fixable within Windows (like the internal drive, the USB drives are formatted with NTFS), others I've had to recreate/rerip even after Windows repairs the drive. Just this morning, I ran chkdsk on a drive we used last night and found four orphaned ("lost") files.

Is this a common issue with these devices using copy/move? Or should I stop using the copy/move routines in the PBO completely, and rather depend on the computers? Is there a umount available anywhere within the UI? Please tell me I don't have to telnet in every time I want to pull a flash drive out of the port...

(I've read threads here on these boards which say things like, "This ain't Windows, you don't need to properly remove the drives," but I've never known a writable file system on any OS that shouldn't have removable drives properly closed down before ripping them out of the USB port. Just seems dangerous to me.)

[snappy46]

You are making a valid point but no there are no way to umount using the UI. I like your example about windows but I must admit that using windows and just pulling out the stick and has rarely been an issue for me. Using linux however which is what the PBO is run on it's a big no no; I run linux at home and never, never, never would I pull out my USB device (HDD /Stick) before unmounting it properly; I loss data many times doing that.

All that being said I would guess that the read/write buffer is very small if any and it is quite possible that the buffer get fully emptied after every write/read operation. I just bought a 1TB USB HDD and just copied everything from my PBO internal HDD to the USB HDD without any issues.

[snappy46]

Suck back and reload; I just prove myself wrong only a few hours after making my previous post. I just tried to copy a 700 MB files from my PBO internal drive to the USB HDD (x3) and it was not successful first time file size=2 MB, second time size = 44MB and third time = 17 MB. Just so you know I did the copy and then umounted the USB HDD using telnet and the file was still small.

Some of the thing I noticed before is that when a HDD or USB Stick is connected after the PBO has already been turn on it mounts it as a read only mount. If the USB stick or HDD is plug in before I turn on the PBO and then turn it on the USB mount is then read/write (rw).

When I had the problem I look and it showed the USB mount as read only; I change it the read/write but the problem also persisted. Very strange since I copied almost 100 GB before from the internal HDD to the USB HDD without any problems.

Anyhow just to be on the safe side I turn off the PBO (back switch) connected the USB HDD and turn PBO back on. Tried again same results. Now the only thing different from before is that I had two torrents being downloaded at the time with a combined download speed of approx. 400 KBps so maybe it is too much for the PBO to handle those two torrent and the file copy to the USB HDD at the same time????? I still have one torrent coming at 300 KBps at this time and my son his watching TV so I will wait until the download is completed and will report my findings.

I would be interested in knowing if you were downloading anything will you were trying your unsuccessful copy. Just for the record I am currently using the ACRBO 4318, bootcode 18.

[snappy46]

UPDATE:

Torrent are done downloading but problem is still there although it copied over 350 MB before it stopped this time. I first use telnet and cp to copy the file .... no problem. Then I did it from my TV only 350 MB copied then stopped. Look at my mounts now it shows my USB mount has being read-only (ro) ???? Very strange it was read/write before I tried to copy the file from internal HDD to USB HDD. It appear that somehow thru the copying process the USB mounts change to read only. Wow this is a new one; the only thing I changed since this worked perfectly was to install PM's last firmware P61 and removed it a day latter and reinstalled 4318. I think it's time for reflash again. :mad: Too many weird problems creeping up.

[CharlieSummers]

I would be interested in knowing if you were downloading anything will you were trying your unsuccessful copy. Just for the record I am currently using the ACRBO 4318, bootcode 18.

Nope, just using shipped P02. (I want fine-grain control of any transfer software I use, so I won't be using the PBO to handle that task.)

And don't make the mistake I made and use MOVE instead of COPY...

[aasoror]

Wow this is a new one; the only thing I changed since this worked perfectly was to install PM's last firmware P61 and removed it a day latter and reinstalled 4318.


Nope, just using shipped P02. (I want fine-grain control of any transfer software I use, so I won't be using the PBO to handle that task.)


I can confirm that this problem was reported on the ACR4318 thread (and was also reported to exist on prior firmwares), I can't dig up the specific post right now.

But as far as I remember they related it to the SDK and said that the 3582 should fix that issue, I would recommend you to test P5-IMS/P61 or ACR4049 or MedBO4241 (all are based on a different SDK than 4318 or P02) and see if this problem persists.

[snappy46]

Thanks aasoror;

Funny that I copied almost 100 GB of data without any problem but when I tried to copy that one file no-go unless I use telnet to do it. Man this box / supporting software is so temperamental that is not even funny. Oh well !!! nothing new here.

[aasoror]

Funny that I copied almost 100 GB of data without any problem but when I tried to copy that one file no-go unless I use telnet to do it. Man this box / supporting software is so temperamental that is not even funny. Oh well !!! nothing new here.

well for the record, I didn't see reports of this failing over local copy (USB), it was (if I remember correctly) reported for over the network transfers.

[snappy46]

Just for info; I tried this morning to copy my TV Shows directory from internal HDD to USB HDD using telnet and I also was not successful. I then check the USB mount it showed has being read/only. Set it back to read/write again and tried again using PBO menus on TV and I look for 1 hours at the process and that time it freaking worked??? I then went on to copy the kids TV show folder and worked as well. :confused:

They only thing I can confirm for certain at 100% since this behaviour has been repeated over and over is that if I have the USB HDD connected and turn on / reboot the PBO the USB will be mounted as read/write (at least at first). If the PBO is already turn on and I connect the USB HDD or Stick it would mount as read only every single time. I first notice that when I was trying out different firmware version using wigout USB method.

These test were conducted using ACRBO 4318, can anyone confirm this kind of behaviour on their PBO running ACRBO or not.

Thank you.

PS: Time to try a new firmware and reformat the HDD..... Again

[wigout]

Hey-

if you do format the hdd, remember to stay on over telnet and watch the ps and check the /tmp/ for a file called script.txt or script0.txt

and for the record, I've had my issues with copying over the network, but a reboot of the player and my wireless bridge has done the trick so far....


-wigout

[snappy46]

Hey-

if you do format the hdd, remember to stay on over telnet and watch the ps and check the /tmp/ for a file called script.txt or script0.txt

and for the record, I've had my issues with copying over the network, but a reboot of the player and my wireless bridge has done the trick so far....


-wigout

The worse part is that I am not even copying over the network I am copying from PBO internal drive to the USB HDD connected to the PBO.

Anything special you want me to look at in the script.txt or script0.txt file. I don't think that just having telnet open will report anything unless I launch ./DvdPlayer app from telnet right ????? or I launch the format process that is normally initiated by DvdPlayer app from telnet. I don't know which script actually do that; or is there even one ???? does the DvdPlayer only launches the required programs it need???? you know .... fdisk, mkfs.ext3, mkswap...etc.....?????? or is there a script that do all that????

Thanks

[wigout]

Well this is what I would do next time I install a fresh firmware and format the harddrive:

Install fresh firmware.
boot up.
get the message to format hard drive.
telnet in with two sessions
in one session, use busybox-mipsel (the fuller static version) that has the watch command.
use it as follows:
busybox-mipsel watch -n 1 ps

(this will run the ps command every second and give you output it to your screen) whatever scripting gets called *should* get captured.

in your second telnet session,
cd /tmp/

select format the harddrive on the screen.

now I'd type ls a few times, seeing what gets created in the tmp directory.

If I read the strings from the DvdPlayer correctly, it supplies the settings to format the harddrive with fdisk as a file, /tmp/script.txt or /tmp/script0.txt

if you see that file cat it or copy it to your /usr/local/etc or usb drive or hard drive.

-wigout

[CharlieSummers]

I can confirm that this problem was reported on the ACR4318 thread (and was also reported to exist on prior firmwares), I can't dig up the specific post right now.

But as far as I remember they related it to the SDK and said that the 3582 should fix that issue, I would recommend you to test P5-IMS/P61 or ACR4049 or MedBO4241 (all are based on a different SDK than 4318 or P02) and see if this problem persists.

I'll cheerfully upgrade the firmware, but not until the serial cable gets here on that slow boat from...oh, right, can't sing here.

I have to admit I'm skittish enough right now not to use at all the internal move/copy commands, instead moving the external drives to one of the desk machines to sort the files. (The internal is kinda on its own, though, because I'm not going to drag the unit and power supply to my office.) I'm also constantly running to a computer to umount via telnet any time I want to remove even a small flash drive. That really should be dealt with in the UI...there's no reason not to have a simple way to properly unmount an external USB drive from the device.

[snappy46]

Well this is what I would do next time I install a fresh firmware and format the harddrive:

Install fresh firmware.
boot up.
get the message to format hard drive.
telnet in with two sessions
in one session, use busybox-mipsel (the fuller static version) that has the watch command.
use it as follows:
busybox-mipsel watch -n 1 ps

(this will run the ps command every second and give you output it to your screen) whatever scripting gets called *should* get captured.

in your second telnet session,
cd /tmp/

select format the harddrive on the screen.

now I'd type ls a few times, seeing what gets created in the tmp directory.

If I read the strings from the DvdPlayer correctly, it supplies the settings to format the harddrive with fdisk as a file, /tmp/script.txt or /tmp/script0.txt

if you see that file cat it or copy it to your /usr/local/etc or usb drive or hard drive.

-wigout

Interesting concept; sorry I was not able to get to that this weekend. Hopefully I will have some time soon but the week doesn't look good between work, nite courses and keeping the family happy. It would certainly be nice to get hold of that script if this is indeed what's going on here so that we can have some control over the formating process and create a partition/format that the firmware would be happy with.

[CharlieSummers]

Why is it I occasionally get an "Invalid Argument" error with the umount command?


/ # umount /tmp/usbmounts/sda1
umount: Couldn't umount /tmp/usbmounts/sda1: Invalid argument

I know I can do a lazy or (ugh) force, but I'm wondering why that particular error?