Sickchill: updateEMBY yields "Looks like we do not have enough disk space to render the page! {error}"

Created on 21 Sep 2020  路  35Comments  路  Source: SickChill/SickChill

Branch/Commit: pip 2020.9.20.post7 99336df163c7e776c7931d864e84d1f0f83afe4d
OS: Ubuntu 18.04 w/Python 3.6.9
Browser: Chrome
What you did: Went to a show page and clicked "Update show in Emby"
What happened: Blank page with text "Looks like we do not have enough disk space to render the page! {error}". Emby did not update.
What you expected: Emby to update the show, no error message.
Logs: Nothing, even with debugging enabled.

I had the same error after moving from git-based install to pip. It was fixed by making /usr/local/lib/python3.6/dist-packages/sickchill/gui/slick/cache a symlink to a directory with the correct permissions. The link is in place and seemingly working since Sickchill works fine otherwise, so perhaps there's another non-writeable directory involved in this case?

This may have been going on for some time/over several releases since it's not something I normally notice.

Bug / Issue

Most helpful comment

This one bugs the crap out of me no end. If you install/update from pip, you need to create/link a cache directory that is writable by the user running SickChill in /usr/local/lib/python3.8/dist-packages/sickchill/gui/slick. My instance runs as the sickchill user and my data directory is in /opt/sickchill which contains a cache directory owned by sickchill.

So after I do an update:

ln -s /opt/sickchill/cache /usr/local/lib/python3.8/dist-packages/sickchill/gui/slick/

This needs to be done every time I update and is a massive pain in the ass and needs to be fixed permenantly.

How about not being a dick? I worked for 5 years to get sickchill to be able to be installed with pip, and to run on python3. Dozens of attempts. It took over 2 million changed lines of code just in the last 3 months.

And after all that, I get pricks being ignorant over a minor inconvenience that I haven't had time to work out yet.

All 35 comments

Issue-Label Bot is automatically applying the label Bug / Issue to this issue, with a confidence of 0.98. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

Hi, thanks for the report. Please use search to make sure your issue has not been reported yet, and someone will try to help you as soon as possible.

This one bugs the crap out of me no end. If you install/update from pip, you need to create/link a cache directory that is writable by the user running SickChill in /usr/local/lib/python3.8/dist-packages/sickchill/gui/slick. My instance runs as the sickchill user and my data directory is in /opt/sickchill which contains a cache directory owned by sickchill.

So after I do an update:

ln -s /opt/sickchill/cache /usr/local/lib/python3.8/dist-packages/sickchill/gui/slick/

This needs to be done every time I update and is a massive pain in the ass and needs to be fixed permenantly.

I have the same issue thought it was my Synology, good to see more have the issue

@JAZ-013 Agreed, that is a bother. But I have created the link, which fixes SickChill general functionality, and I still get this error for the updateEMBY function. So there's got to be something else going on as well.

I should add to the bug description that the automated function to update EMBY on new content discovered also doesn't seem to be working.

This one bugs the crap out of me no end. If you install/update from pip, you need to create/link a cache directory that is writable by the user running SickChill in /usr/local/lib/python3.8/dist-packages/sickchill/gui/slick. My instance runs as the sickchill user and my data directory is in /opt/sickchill which contains a cache directory owned by sickchill.

So after I do an update:

ln -s /opt/sickchill/cache /usr/local/lib/python3.8/dist-packages/sickchill/gui/slick/

This needs to be done every time I update and is a massive pain in the ass and needs to be fixed permenantly.

How about not being a dick? I worked for 5 years to get sickchill to be able to be installed with pip, and to run on python3. Dozens of attempts. It took over 2 million changed lines of code just in the last 3 months.

And after all that, I get pricks being ignorant over a minor inconvenience that I haven't had time to work out yet.

Sure motivates me to keep working on it 馃檮

Sorry if my "that is a bother" came off as criticism as it most definitely wasn't intended that way. At all.
I have appreciated your hard work for years, and been a passive bystander to the turbulence surrounding the development and forkings of the project, from which you have come out on top. I think very few of us users have any idea how much effort you actually put into this project.

@einarsi that was not what irritated me. It was the bugs the crap out of me no end and the massive pain in the ass and needs to be fixed permenantly like I owe something to him. I'm sure the literal thousands of hours I have spent on the development of this free software warrants a little effort taking the 2 seconds to make a symlink for this 'massive pain in the ass'.

Nevertheless, the cache dir symlink is no more.
https://github.com/SickChill/SickChill/commit/6c8fa23ffe9bae68a136498820968008e859ec9c#diff-9f344c8cfac62fbbc308a499aa0c0fe8L129-L146
https://github.com/SickChill/SickChill/commit/6c8fa23ffe9bae68a136498820968008e859ec9c#diff-83415690294a25e906bd4e417451f9e3R31-R47
https://github.com/SickChill/SickChill/commit/6c8fa23ffe9bae68a136498820968008e859ec9c#diff-83415690294a25e906bd4e417451f9e3R132-R144

Just got home from work and updated to 2020.9.22.post2. Can confirm that there is no longer a need for cache-link for Sickchill to operate properly - excellent work! However, I am afraid that updateEMBY still results in the issue described.

It seems that the root cause for the error is a recent change in my network configuration which leads to sickchill not being able to connect to emby by DNS anymore. Changing to IP fixed the issue. Perhaps it's something similar for you, @spoelly ?

The error message talking about lack of diskspace is hugely misleading, especially with the previously existing cache issue, and led me down the wrong path. But adding a couple of debug lines put me on the right track.

There's a slight bug in https://github.com/SickChill/SickChill/blob/master/sickchill/views/index.py#L187:
return Template("Looks like we do not have enough disk space to render the page! {error}").render_unicode(error=error)
should be
return Template("Looks like we do not have enough disk space to render the page! ${error}").render_unicode(error=error)
to show the actual error message

The leading text may preferably be amended as well to something like this:
return Template("OSError encountered! ${error}").render_unicode(error=error)

Got the exact same issue fixed ip works indeed but would like to get it working on DNS

I will update that error message later. Never came across another oserror there that was not permissions/freespace before lol.

What exactly is the real error? If it is an IP6 resolution it explains it, otherwise idk

@einarsi Thanks for debugging the issue. I would like to fix whatever else is the problem but for now I have fixed the error page to show the correct data (and make it pretty even when there really is no disk space)

@einarsi @spoelly https://github.com/SickChill/SickChill/commit/df3a25eca69ec64a96ebe6c0169391d93eb4eee3
Please let me know the URL you are trying to use and what the error says

How about not being a dick? I worked for 5 years to get sickchill to be able to be installed with pip, and to run on python3. Dozens of attempts. It took over 2 million changed lines of code just in the last 3 months.

And after all that, I get pricks being ignorant over a minor inconvenience that I haven't had time to work out yet.

Geezuz fuck. How was I being a prick? It bugs me. I was being honest. If giving a solution to the problem is considered "being a dick" then I'm happy to delete my comment and keep my solutions to myself in the future. I'm sorry I didn't blow smoke up your ass or suck your dick in the process. So maybe just chill the fuck out, dude. I wouldn't be here if I didn't love you and your software. Next time, I promise I'll send flowers and large bags of cash when I comment that something is annoying.

@einarsi that was not what irritated me. It was the bugs the crap out of me no end and the massive pain in the ass and needs to be fixed permenantly like I owe something to him. I'm sure the literal thousands of hours I have spent on the development of this free software warrants a little effort taking the 2 seconds to make a symlink for this 'massive pain in the ass'.

Nevertheless, the cache dir symlink is no more.
6c8fa23#diff-9f344c8cfac62fbbc308a499aa0c0fe8L129-L146
6c8fa23#diff-83415690294a25e906bd4e417451f9e3R31-R47
6c8fa23#diff-83415690294a25e906bd4e417451f9e3R132-R144

Again, I'm sorry. Did it not "need to be fixed permenantly"...? It did, didn't it? So I was stating a fact, do you think? I'm sorry I didn't fuck around and blow smoke up your ass. I've been a developer for 25 years. I don't feel the need to coddle to your ego. If you want your dick sucked every time you write 2 million lines of code, you're in the wrong industry. No, you don't owe me anything. But I don't owe you anything either and if you're going to be a fucking snowflake when someone writes a comment that uses a couple of words you don't like, then I'll stop supporting your project. I know you won't care if I do and are probably thinking "go ahead" but at least I won't have to deal with this bullshit.

Lastly, thanks for fixing this problem in such a timely manner. I really appreciate it.

I don't work for you. I literally do not have to do any of this.

There is a big difference between "hey, I'm having this problem, here is all the information I know about the problem, could you try and fix it?" And "THIS IS FUCKING ANNOYING YOU NEED TO FIX IT NOW"

I don't HAVE to fix anything. I did not fix it for you. I fixed it because there are 10k+ other users that are mostly civil when they ask for help, and a handful had this problem and were not demanding dicks when they reported it.

You also did not provide a "solution". You copy and pasted the solution I gave in the 5 or so other issues about this exact error.

When you are paying someone to do something you can demand they do things, you can jump their shit or whatever because since you are paying them they owe you something in return.

I donate my time and my limited skills for free, because I CHOOSE to. And for no other reason. I therefore have already GIVEN you more than you have earned, which is my time and effort.

You can try and swing your little dick around all you want, but I've been a developer for about 25 years myself and I don't owe anyone a damn thing. Not even the bank.

So next time, be polite and ask and I will help if I can. If you can't do that, fix it your damn self.

I don't work for you. I literally do not have to do any of this.

There is a big difference between "hey, I'm having this problem, here is all the information I know about the problem, could you try and fix it?" And "THIS IS FUCKING ANNOYING YOU NEED TO FIX IT NOW"

I don't HAVE to fix anything. I did not fix it for you. I fixed it because there are 10k+ other users that are mostly civil when they ask for help, and a handful had this problem and were not demanding dicks when they reported it.

You also did not provide a "solution". You copy and pasted the solution I gave in the 5 or so other issues about this exact error.

When you are paying someone to do something you can demand they do things, you can jump their shit or whatever because since you are paying them they owe you something in return.

I donate my time and my limited skills for free, because I CHOOSE to. And for no other reason. I therefore have already GIVEN you more than you have earned, which is my time and effort.

You can try and swing your little dick around all you want, but I've been a developer for about 25 years myself and I don't owe anyone a damn thing. Not even the bank.

So next time, be polite and ask and I will help if I can. If you can't do that, fix it your damn self.

Wow. OK. Firstly, LOLs. Second, where did I say any of that? I didn't say "YOU NEED TO FIX IT NOW". I just said it needs to be fixed permenantly, after providing MY non-cut-and-paste, totally hand-typed solution to the problem. I don't hang out on Github so I haven't seen any other reports of this problem. This one was just at the top when I finally decided to look into it. Anyway, it DID need to be fixed permenantly, didn't it? Which is why I said it. Seriously, go back and read what I wrote. I was blunt and to the point, not rude. If you think that's rude, then you're the one with the problem, not me. Maybe you don't think highly enough of yourself. May be if you didn't have such a negative attitude SickRage wouldn't have been hijacked, Dustyn.

Anywayz, you've now got 10k-1 users because you're such an arrogant fuck I've switched to another SickBeard fork. Byeee!!!! :D

馃檮 Blocked

Just to be clear: This is not an issue with sickchill at all, but my network setup. I run sickchill in a virtual host that is connected to the web using VPN. When the VPN connects, /etc/resolv.conf get updated to use an external DNS resolver and the host can no longer resolve local DNS addresses. I fixed it the easiest way I could think of: By using IP instead of DNS.

This issue can easily be reproduced by specifying an invalid IP or DNS under Settings->Notifications->Emby.

Error message:
ConnectionError: HTTPConnectionPool(host='tugboat.home', port=8096): Max retries exceeded with url: /emby/Library/Series/Updated?tvdbid=_removed_ (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or service not known',))

I still got the same issue and not showing an other error strangely i am using the package of BenV on my synology. The url i am connection to is http://myhost.mydomain:port/ wich goes to http://192.168.2.3:8899

log is not showing anything..

@spoelly Just "mydomain"? Not "myhost.mydomain"? That doesn't look right.

I don't know anything about BenV or Synology. Is it an updated build based on the master branch from yesterday? Do you see the new error page that replaces the original error message on plain background? If so: Click the "Show/Hide Error"-button to see the traceback.
Can you try to resolve the same DNS using another app on the Synology? If it resolves then there may be something wrong with the SickChill build you are using. If it doesn't resolve then I guess there is an issue with either the address or the DNS setup on your Synology.

@einarsi sorry my bad your are correct with the url..
The package is just for initial install and is being updated bij GIT using the normal UI update proces. All other web applications on my syno are working fine. Will check my DNS setup.

Can't find any errors in my log :(

@spoelly benjv package is discouraged. we have an official package. https://github.com/SynoCommunity/spksrc/pull/4161
Also, Im getting ready to push a fix that catches this error.

@miigotu thanks can i restore a backup on this package from my current install?

@miigotu
Like the new error page!

But check the log:

Traceback (most recent call last): File /volume1/@appstore/sickchill/var/src/sickchill/views/index.py:185, in async_call: return function(**kwargs) File /volume1/@appstore/sickchill/var/src/sickchill/views/home.py:660, in update: if updater.update(): File /volume1/@appstore/sickchill/var/src/sickchill/update_manager/runner.py:313, in update: return self.updater.update() File /volume1/@appstore/sickchill/var/src/sickchill/update_manager/git.py:302, in update: notifiers.notify_git_update(settings.CUR_COMMIT_HASH or "") File /volume1/@appstore/sickchill/var/src/sickchill/oldbeard/notifiers/__init__.py:91, in notify_git_update: n.notify_git_update(new_version) File /volume1/@appstore/sickchill/var/src/sickchill/oldbeard/notifiers/pushover.py:139, in notify_git_update: self._notifyPushover(title, update_text + new_version) File /volume1/@appstore/sickchill/var/src/sickchill/oldbeard/notifiers/pushover.py:165, in _notifyPushover: return self._sendPushover(message, title, sound=sound, userKey=userKey, apiKey=apiKey) File /volume1/@appstore/sickchill/var/src/sickchill/oldbeard/notifiers/pushover.py:83, in _sendPushover: urllib.parse.urlencode(args), {"Content-type": "application/x-www-form-urlencoded"}) File /var/packages/python3/target/lib/python3.7/http/client.py:1252, in request: self._send_request(method, url, body, headers, encode_chunked) File /var/packages/python3/target/lib/python3.7/http/client.py:1298, in _send_request: self.endheaders(body, encode_chunked=encode_chunked) File /var/packages/python3/target/lib/python3.7/http/client.py:1247, in endheaders: self._send_output(message_body, encode_chunked=encode_chunked) File /var/packages/python3/target/lib/python3.7/http/client.py:1026, in _send_output: self.send(msg) File /var/packages/python3/target/lib/python3.7/http/client.py:966, in send: self.connect() File /var/packages/python3/target/lib/python3.7/http/client.py:1422, in connect: server_hostname=server_hostname) File /var/packages/python3/target/lib/python3.7/ssl.py:423, in wrap_socket: session=session File /var/packages/python3/target/lib/python3.7/ssl.py:870, in _create: self.do_handshake() File /var/packages/python3/target/lib/python3.7/ssl.py:1139, in do_handshake: self._sslobj.do_handshake() SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)

i am not using SSL for this..

Ow wait is it pushover??

@miigotu thanks can i restore a backup on this package from my current install?

Yes

And yes that is an error in pushover

Pushover configuration does not let me configure this in Sickchill so is this a bug in the implementation? or is it my setup?

If you disable ssl verify in settings that error goes away

I'll look into that one myself.

Thanks i will move to the synocommunity install

i can confirm pushover is working again

Was this page helpful?
0 / 5 - 0 ratings