3psus
-
Posts
19 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by 3psus
-
-
On 2017-02-18 at 2:46 AM, kubed_zero said:
In the meantime, I'll check this out! Thanks!
Update. Got it working, after a little bit of struggle. UnRAID doesn't have compile tools so this guide didn't really help: http://www.gilandre.net/cgi-bin/wiki.cgi/NMONUnderSlackware. I then downloaded a binary and copied it to /boot/extra (from what I hear it gets installed automatically from there at boot): https://slackware.pkgs.org/14.2/slackers/nmon-16f-x86_64-3cf.txz.html
However, upon running it I got the "nmon: error while loading shared libraries: libncurses.so.6: cannot open shared object file: No such file or directory" message. Okay, time to upgrade ncurses. I originally installed some random ncurses-6.0 but it didn't include/install libncurses so I went back and installed ncurses from here: http://packages.slackware.com/?r=slackware-current&p=ncurses-6.0-i586-2.txz by copying it to my boot/extra folder and then running upgradepkg on it. Still the same error though since it didn't install as libncurses.so.6, only libncurses.so. Then I symlinked /usr/lib64/libncurses.so.6 to /usr/lib64/libncurses.so and /usr/lib64/libtinfo.so.6 and it worked!
Thx kubed!
For those on 64bit system, this is the good package: http://packages.slackware.com/?r=slackware64-current&p=ncurses-6.0-x86_64-2.txz
-
Yeah, you might be right. I actually thought there was a newer release of curl, but that is not the case. Anyways, it is done now, at least the maintainer will be notified about the issue and can apply the patch in a sub-release, like has been done on many other distros
. I understand he might wait to the next stable release of curl though. I must say I find it surprising that libcurl hasn't had a new stable release after this but whatever. Thanks binhex for the suggestions. Seems like a roll back is the solution here.
ref.
https://github.com/curl/curl/issues/1174
https://www.freshports.org/ftp/curl
thanks for the links above, tracked it back via github and arch already have the patch in place, i wondered why i wasnt seeing the issue
Np! By the way, for anybody wanting to roll back, it is as easy as appending ":52" to the "Repository" field and update the container.
-
I've got the "Tracker: [Timeout was reached]" error also, but only for 2 trackers out of 5. This has appeared after last docker update, which also coordinates with a modem/router replacement (new model). Port forwarding seems fine, as reported by rutorrent. rtorrent version is not blacklisted on any of those trackers. Any ideas where this issue could come from?
This seems to be related to curl. See notes for version 7.52.1_1 : https://www.freshports.org/ftp/curl and https://github.com/rakshasa/rtorrent/issues/538
I flagged the curl package out of date here so we can upgrade from apk as soon as possible : https://pkgs.alpinelinux.org/package/edge/main/x86/libcurl
Edit: Also if we can get an update for the container with an upgraded curl, that would be awesome
you flagged a package that is up to date with the latest release, as out of date ?
you're going to be popular with alpine, lol.
Yeah, you might be right. I actually thought there was a newer release of curl, but that is not the case. Anyways, it is done now, at least the maintainer will be notified about the issue and can apply the patch in a sub-release, like has been done on many other distros
. I understand he might wait to the next stable release of curl though. I must say I find it surprising that libcurl hasn't had a new stable release after this but whatever. Thanks binhex for the suggestions. Seems like a roll back is the solution here.
ref.
-
I've got the "Tracker: [Timeout was reached]" error also, but only for 2 trackers out of 5. This has appeared after last docker update, which also coordinates with a modem/router replacement (new model). Port forwarding seems fine, as reported by rutorrent. rtorrent version is not blacklisted on any of those trackers. Any ideas where this issue could come from?
This seems to be related to curl. See notes for version 7.52.1_1 : https://www.freshports.org/ftp/curl and https://github.com/rakshasa/rtorrent/issues/538
I flagged the curl package out of date here so we can upgrade from apk as soon as possible : https://pkgs.alpinelinux.org/package/edge/main/x86/libcurl
Edit: Also if we can get an update for the container with an upgraded curl, that would be awesome
-
I've got the "Tracker: [Timeout was reached]" error also, but only for 2 trackers out of 5. This has appeared after last docker update, which also coordinates with a modem/router replacement (new model). Port forwarding seems fine, as reported by rutorrent. rtorrent version is not blacklisted on any of those trackers. Any ideas where this issue could come from?
-
Great answer Gary, huge thanks!
Definitely turning turbo write on now.
-
If all disks are already spinning you shouldn't notice any slowdowns in streaming. It WOULD require a few extra seeks on the disk that was currently streaming, but these are fast enough that there shouldn't be any issues with a movie stream. It's the spin-up delay that can cause problems ... and since you don't have anything to spin up, you'd be fine.
I understand, thanks for the clarification. Streaming aside, would there be any noticeable impact on reads going on, wether it be in latency or in read speed? Or is it marginal to the point that it wouldn't be noticeable?
-
* Another possible problem if you were in Turbo mode, and you are watching a movie streaming to your player, then a write kicks in to the server and starts spinning up ALL of the drives, causing that well-known pause and stuttering in your movie. Who wants to deal with the whining that starts then?
If you never spin down your disks, then this is likely to improve performance for writes.Very interesting, I wasn't aware of this feature. Is there any reason to not enable this if I always keep my disks spinning?
I feel like Scott's question deserve's a little more attention. From what Rob wrote, it seems like turbo write could worsen read operation currently going on while other disks are spun up, like when watching a movie. In my environment, disks are never spun down anyways so spinning them up for a small write isn't an issue.
My main question is: if all disks are always spinning, am I going to be penalized in read operations if I turn turbo write on? Is the wait time mentioned in the movie example only caused by the time it takes for other disks to spin up or is there any other variables in play?
Thanks for this great article Rob!
-
Browser cache and cookies?
Believe it or not, it was Lastpass' autologin or autofill features that were breaking plexpy's settings page.
-
Mine is working great. Maybe someone can get a fix from my settings. Also try running the Fix Common Problems plug-in to see if you have other issues getting in the way (found in Community Applications add-on).
Thx for the app (Fix Common Problems) suggested. It did find issues wich I solved right away. After that, I decided to start from scratch. I created a new docker image, added the dockers with the same mappings except for plexpy, which I created a new directory in /mnt/cache/appdata/plexpy
I then opened the webui and to my surprise, it still had the same settings with the same ID and password for webui authentication. I really am clueless about all of this. Where else does this docker keep it's info? After deleting the docker image and the /conf directory (for me /mnt/cache/appdata/plexpy), what else is there to delete?
-
Just installed the docker and I am having difficulties with the settings page. First off, I generated a username and a password to access plexpy webui. I saved and restarted the container and all was good, username and password now showing in the webui. I went on changing some settings but as soon as I would save and restart the container, all changes had vanished. I could still see the username and password there, but anything that I changed after that didn't seem to be persistent.
I tried to remove the username and password as a test, but when the container was restarted, they were still there in the settings page although plexpy didn't ask me to authenticate before loggin in. So the settings were saved but not persistent anymore in the webui. In config.ini, I can see all changes are registered.
Last thing I tried was to delete the container and reinstall from scratch. To my surprise, as soon as i accessed the settings page for the first time, the first username and password that I had saved were still there.
I have /logs mapped to /mnt/cache/appdata/plex/Library/Application Support/Plex Media Server/Logs/ and /config
and /config mapped to /mnt/cache/appdata/plexpy/
Other than that, everytime I access the settings page, I get asked to backup the config file. Also, whe I click "check for update", I just get redirected to the main page. Everything else works as expected. Anybody else having those issues or knows what could be causing it?
Thanks!
Still have the same issue with latest updates. I have been able, after deleting and reinstalling multiple times (I think what solved it was to recreate the docker image), to get rid of those issues for a while but now with the latest plexpy update, same problems as stated in quoted post are back. What's up with that? I need enlightenment. Could somebody provide some guidance?
Edit: To clarify, I just deleted the conainer and the image yet again and I am still presented first with the welcome page, then after restarting the docker, with a log in page that asks for the *same* user and password that was set *before* deleting everything.
-
+1 would love a Seafile docker as well
-
Hi people! Hopefully someone can help me. In the last days, I've had an issue with vnc where I cannot control the cursor in the vnc. It's as if my main cursor will go underneath the crashplan screen and I cannot move the vnc cursor, neither click. I can still use the keyboard though, and the vnc screen is definitely working.
I have been using this docker for couple weeks with no issues before now. I should say that I recently had the cache ssd fail, which may have corrupted some data although I have not had any reason to believe so yet. Here are the logs from the docker, there are couple errors but I am not sure if they are relevant or not:
Fri Aug 12 17:34:05 2016 Connections: closed: 127.0.0.1::47619 (Clean disconnection) EncodeManager: Framebuffer updates: 40 EncodeManager: Tight: EncodeManager: Solid: 45 rects, 3.46657 Mpixels EncodeManager: 720 B (1:19259.5 ratio) EncodeManager: Bitmap RLE: 8 rects, 1.706 kpixels EncodeManager: 312 B (1:22.1795 ratio) EncodeManager: Indexed RLE: 45 rects, 75.863 kpixels EncodeManager: 3.82129 KiB (1:77.6877 ratio) EncodeManager: Tight (JPEG): EncodeManager: Full Colour: 28 rects, 525.251 kpixels EncodeManager: 126.924 KiB (1:16.1679 ratio) EncodeManager: Total: 126 rects, 4.06939 Mpixels EncodeManager: 131.753 KiB (1:120.662 ratio) Terminating WebSockets proxy (137) _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/Tower:1 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root Xvnc TigerVNC 1.6.0 - built Dec 24 2015 16:05:46 Copyright (C) 1999-2015 TigerVNC Team and many others (see README.txt) See http://www.tigervnc.org for information on TigerVNC. Underlying X server release 11202000, The X.Org Foundation Fri Aug 12 17:34:21 2016 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 4239 vncext: created VNC server for screen 0 Aug 12 17:34:21 Tower syslog-ng[40]: syslog-ng starting up; version='3.5.3' Warning: could not find self.pem Using local websockify at /opt/novnc/utils/websockify/run Starting webserver and WebSockets proxy on port 4280 Navigate to this URL: http://Tower:4280/vnc.html?host=Tower&port=4280
-
Just installed the docker and I am having difficulties with the settings page. First off, I generated a username and a password to access plexpy webui. I saved and restarted the container and all was good, username and password now showing in the webui. I went on changing some settings but as soon as I would save and restart the container, all changes had vanished. I could still see the username and password there, but anything that I changed after that didn't seem to be persistent.
I tried to remove the username and password as a test, but when the container was restarted, they were still there in the settings page although plexpy didn't ask me to authenticate before loggin in. So the settings were saved but not persistent anymore in the webui. In config.ini, I can see all changes are registered.
Last thing I tried was to delete the container and reinstall from scratch. To my surprise, as soon as i accessed the settings page for the first time, the first username and password that I had saved were still there.
I have /logs mapped to /mnt/cache/appdata/plex/Library/Application Support/Plex Media Server/Logs/ and /config
and /config mapped to /mnt/cache/appdata/plexpy/
Other than that, everytime I access the settings page, I get asked to backup the config file. Also, whe I click "check for update", I just get redirected to the main page. Everything else works as expected. Anybody else having those issues or knows what could be causing it?
Thanks!
. I understand he might wait to the next stable release of curl though. I must say I find it surprising that libcurl hasn't had a new stable release after this but whatever. 
docker compose?
in Feature Requests
Posted · Edited by 3psus
Thanks for this, I've seen Portainer being used before and definitely liked my first impressions.
My 2 cents as far as a GUI goes for docker compose: I'd really only be looking for a text field where I can copy/paste the YML content, which would then add that container to the unRaid containers management page, just like any other that would have been added using a template. I just feel that would be the natural way of doing things with docker in unRaid using compose, but that's just my personal impression.
Been thinking about the Portainer option while writing this though, and I'm more and more inclined towards it. Thanks again!