hurricanehrndz

Thanks, The pulling layers is fine. I discovered the issue. The problem is I change to using the phusion base image like everyone else, unfortunately I forgot that phusion uses trusty and that the x11vnc release in trusty hates it when you disable ipv6. unRAID by default doesn't have ipv6 enabled for docker and so x11vnc errors out with a buffer overrun. Anyhow I'm trying to resolve the issue while keeping the base image phusion. I promise you I tested the build before the release the problem is that I tested it on a ubuntu virtual desktop were ipv6 is not disabled. So when I release it I thought that issues like this weren't going to happen. My apologies. Just to give you heads up the container also support rdp now, so that another method you might be able to access once I get the issues resolved. Please reply rather than editing your message so that I may get notified. I will try and have this fix as soon as possible.

This might a docker error. I will double check it, maybe I have to recreate the repository from scratch since I made some major overhaul. Can you please retry again, and report back.

Thanks. I will update it soon.

You can updated yourself, I was sure I had design it this way. Stop the container. Replace the jar file in the config directory with the new version and and ensure the permission are right.

I will update it shortly. Thanks for the post. If you wanted to do it manually docker exec would be the best, I will update the image though. unRAID best practice suggest all updating be done by developers and not the containers themselves.

Yes you can. Are you running the docker version or just the actual java install? If using docker with the new image https://registry.hub.docker.com/u/hurricane/tinymediamanager/ I would use docker exec -ti containername /scripts/tinyMediaManangerCMD.sh $PARMS replace containername with the name of your container and replace $PARMS with available options, please tinyMediaManager readme or forum for this info.

Ok

You can updated yourself, I was sure I had design it this way. Stop the container. Replace the jar file in the config directory with the new version and and ensure the permission are right.

I will look at it today for you.

Ubooquity: Ubooquity is a free, lightweight and easy-to-use home server for your comics and ebooks. Use it to access your files from anywhere, with a tablet, an e-reader, a phone or a computer. gitub: https://github.com/HurricaneHernandez/ubooquity docker repo: https://registry.hub.docker.com/u/hurricane/ubooquity/ template: https://github.com/HurricaneHernandez/container-templates You can adjust the port Ubooquity runs on by providing the environment variable UBOOQUITY_PORT with which port you wish. The link in the template will obviously be broken though, so you might have to adjust it manually. Please visit once installed http://ip:8085/admin or if you used the template just click the image.

Perhaps once I start using circus I can achieve this. In terms of tmm, I really like. It seems to be doing really well. I use it in conjunction with MediaBrowser.

I will create a template shortly. I'm also updating the image from supervisor to circus, because I would like the boot process of the container to be more fail safe.

https://registry.hub.docker.com/u/hurricane/tinymediamanager/ PS it might still be building.

I don't believe so, since sleep is run before line 1451 which is echo $clearscreen$goto_top${bold}Pre-Clear unRAID Disk $theDisk$norm So the exit code being stored in $smartstat should be that of smartctl. If this is not the case please forgive my statement. On another note, I noticed that when I did run pre-clear that all the reports look valid so its only this line that causes issues for people and gives them a confusing error that could possibly not be an error, like in my particular case. Uploaded with ImageShack.us PS: Here is the pre-clear report from this disk using v11, before I though off inserting the 5 second delay: http://pastebin.com/JJBE52gp Pre-clear issued the error at the start of preclear "smartctl may not be able to run on...." so on, yet as you can see the rpt clearly shows the smartctl was able to run. Thanks again Joe L. for putting up with my pestering. I love your script though, and like to contribute whenever possible.

I've no idea... Best I can offer is to suggest you invoke it as sh -xv preclear_disk.sh /dev/sdX and see what it is doing. I certainly cannot fix your exit status if your smart command is exiting abnormally. Joe L. Thanks Joe L. Just thought I asked since it only occurs within the script, not from the command line or from within my test script which is practically identical to the offending lines in the pre-clear script. Anyhow I'll do some more test and run the command as you suggested. Edit: Did more tests, I added a 5 second sleep at line 1450 and that seem to resolve the issue.

Yes. Same results exit code 4, when it should be zero.

When you run the command, are you checking its exit status? the preclear script is, and your smartctl is exiting with a non-zero exit status. Try the 1.12 version of the preclear_disk.sh script attached to this post: http://lime-technology.com/forum/index.php?topic=4068.msg128289#msg128289 It is version 1.12... I had originally posted it there to allow those with 3TB drives to give it a try, but it also should fix your issue too. (as long as your disk will report with just smartctl -a /dev/sdX ) I would really appreciate some help because I am still receiving the error with version 12. Now the disk that is being tested is connected to SASLP card. Yet I receive a normal output when I run the command smartctl -a /dev/sdb. Furthermore I wrote a small bash script that looks like follows: http://pastebin.com/42nSRWXZ And it exits with a code of 0. Yet when I modified the your preclear script and inserted an echo line between lines 1456 and 1457 that said "echo $smartstat" I got an exit code 4. Can you please advise me as to what exactly is occurring and how I may resolve the issue.