Local file casting issues

[theychx]

Howdy

Trying to cast this media file on my CC Ultra:
youtube-dl -f "best[width <=? 3840][height <=? 2160]" https://vimeo.com/225888984
as a local file, results in this traceback:

Traceback (most recent call last):
  File "/home/benno/projects/chromecast/catt/catt/http_server.py", line 40, in do_GET
    self.wfile.write(data)
  File "/usr/lib/python3.6/socketserver.py", line 775, in write
    self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe
192.168.0.188 - - [27/Feb/2018 12:43:54] "GET / HTTP/1.1" 200 -
Traceback (most recent call last):
  File "/home/benno/projects/chromecast/catt/catt/http_server.py", line 40, in do_GET
    self.wfile.write(data)
  File "/usr/lib/python3.6/socketserver.py", line 775, in write
    self._sock.sendall(b)
ConnectionResetError: [Errno 104] Connection reset by peer

Served from a DLNA-server, the file plays fine (I did check transcoding settings).

It would be nice to have this fixed, before we axe py2 support. I tried tinkering a bit with the server module, but to no avail.

Upon further investigation, this does not appear to be bitrate related. The Chromecast and the server script are somehow confusing each other when trying to cast certain types of videos. Please note that all the media files that I have had issues with originated from Vimeo (and that regular casting of Vimeo videos with catt is also flakey).

[skorokithakis]

Hmm... "Connection reset by peer" generally means that the client saw some error and aborted the request. I'm not sure what that error could be, though. We might be sending something wrong.

When you play the file from a DLNA server, does it go through your Chromecast? I don't think the Chromecast can do DLNA, can it?

[theychx]

When you play the file from a DLNA server, does it go through your Chromecast? I don't think the Chromecast can do DLNA, can it?

DLNA uses http, so yes.

[theychx]

Oops, closed by github magic.

[theychx]

@skorokithakis Could it be that the file is borked somehow, and that the DLNA-server is somehow mitigating this? Have you had issues with local file casting?

[skorokithakis]

I didn't have any issues when testing it, but most of my casting is online, so I haven't tested it extensively, I'm afraid. I can test when I get home.

[theychx]

@skorokithakis Any progress?

[skorokithakis]

Ah, sorry, completely forgot. Looks like we made a booboo:

  File "/home/stavros/.local/lib/python3.6/site-packages/pychromecast/discovery.py", line 114, in discover_chromecasts
    stop_discovery(browser)
UnboundLocalError: local variable 'browser' referenced before assignment

[skorokithakis]

Err, that's pychromecast code. The previous exception is:

    listener, browser = start_discovery(callback)
  File "/home/stavros/.local/lib/python3.6/site-packages/pychromecast/discovery.py", line 88, in start_discovery
    ServiceBrowser(Zeroconf(), "_googlecast._tcp.local.", listener)
  File "/home/stavros/.local/lib/python3.6/site-packages/zeroconf.py", line 1696, in __init__
    socket.inet_aton(_MDNS_ADDR) + socket.inet_aton(i))
OSError: [Errno 105] No buffer space available

but it just seems that we need to show "no Chromecasts found" or something like that.

[skorokithakis]

It just fails immediately, which suggests to me that there's some sort of interface error.

[theychx]

I'm a bit confused now, how does this relate to local file casting? (and how did you get that traceback?)

[skorokithakis]

Sorry, this is just what I got when trying to cast a local file (it's just what catt cast dies with), it fails when discovering Chromecasts. It's not very relevant to this bug, but I got blocked by it in testing this bug. I will investigate further!

[theychx]

@skorokithakis While working on the server stuff, I discovered what causes (at least some of) the issues with the current script. I made this branch, in case you want to push the fix to python 2 users.

[skorokithakis]

Ah, hmm. I can branch from 0.5.5 into a py2 branch and issue a 0.5.6 release from that code (which won't contain your py3 removal code), but it's going to get harder to backport things after that, as releases are going to be weird. It's still early enough that we can do this, though.

[theychx]

Quick question (my git-foo is on a fairly low level):
My branch DOES contain the py2 compat code. I checked out from the 0.5.5 tag, and then fixed http_server.py, and then created a new branch, made the commit, and then pushed this branch to github. Did I misunderstand something?

[skorokithakis]

Oh, no, I was just saying that we may want to keep a py2-compat branch around to work on/backport things. The main problem is that we can't really have two release "paths", one for py2 and one for py3, so we can't really say "0.6.0 dropped python2 compatibility, but 0.6.1 reinstated it again because we wanted to make some bugfixes, and then 0.6.2 drops it again".

I'll just release 0.5.6 from your branch now, thanks.

[theychx]

Makes sense.

[skorokithakis]

Alright, after a lot of failures, I did manage to release 0.5.6. Unfortunately, there won't be a tag and release on Github, as we don't have a commit to tag, but it's out! Thank you!