Installed but just receiving 404s in logs

[tinycg]

After installing FFMPEG, the proper GCC tweaks for ML and having the script run successfully (minus the caveat of the "missing" config file from the other issue.) I get Wallop to load, can reach the server page for it, it correctly shows channels but when I go to the stream page for a channel it just continues to spin and I receive the following on the command line:

127.0.0.1 - - [02/Jul/2013 17:44:32] "POST /channels/504/tune HTTP/1.1" 200 29 0.0030 127.0.0.1 - - [02/Jul/2013 17:44:32] "GET /channels/504 HTTP/1.1" 200 2406 0.0047 127.0.0.1 - - [02/Jul/2013 17:44:32] "GET /channels/504.m3u8 HTTP/1.1" 404 - 0.0014 127.0.0.1 - - [02/Jul/2013 17:44:32] "GET /channels/504/status HTTP/1.1" 404 - 0.0014 127.0.0.1 - - [02/Jul/2013 17:44:32] "GET /favicon.ico HTTP/1.1" 404 447 0.0015 127.0.0.1 - - [02/Jul/2013 17:44:33] "GET /channels/504/status HTTP/1.1" 404 - 0.0011 127.0.0.1 - - [02/Jul/2013 17:44:34] "GET /channels/504/status HTTP/1.1" 404 - 0.0011 127.0.0.1 - - [02/Jul/2013 17:44:35] "GET /channels/504/status HTTP/1.1" 404 - 0.0011

I've seen it throw 420 and 404 codes on the .m3u8 step as if its not creating the file or something, any help would be great, this is an AWESOME project.

[dbussert]

My install is working properly, but I have seen 404 errors when I've opened up multiple channels very quickly. I wonder if the HDHomerun is hitting its 3 tuner max and itself is giving 404 errors because all tuners are in use. I also saw a 404 when I went to a channel page, http://192.168.1.100:8888/channels/505, let it reach ready state and then let it sit until the ffmpeg process times out. Then refresh the page and the log is all 404 errors.

192.168.1.20 - - [03/Jul/2013 03:18:34] "GET /channels/505/status HTTP/1.1" 404 - 0.0387

[maddox]

Wallop 404s if there is no transcoding session available for that channel.

The periodic requests for the m3u8 keep the session alive. Once there hasn't been a request for it for more than a minute, the session is killed.

It's important to remember that the web views were laid on top of the API.

Better feedback could exist though.

On Jul 2, 2013, at 11:18 PM, dbussert notifications@github.com wrote:

My install is working properly, but I have seen 404 errors when I've opened up multiple channels very quickly. I wonder if the HDHomerun is hitting its 3 tuner max and itself is giving 404 errors because all tuners are in use. I also saw a 404 when I went to a channel page, http://192.168.1.100:8888/channels/505, let it reach ready state and then let it sit until the ffmpeg process times out. Then refresh the page and the log is all 404 errors.

192.168.1.20 - - [03/Jul/2013 03:18:34] "GET /channels/505/status HTTP/1.1" 404 - 0.0387

— Reply to this email directly or view it on GitHub.

[maddox]

minus the caveat of the "missing" config file from the other issue.

fixed in a945ce368cb1e38eadb3fbd172c1332854a83a0f

[maddox]

Ok so what happens in the Wallop frontend is that it sends a TUNE signal to the server when you PICK a channel. It then immediately redirects to the channel page. When on the channel page it polls the transcodign session status until it sees that the stream is ready to be consumed, it then starts up the video player and plays.

127.0.0.1 - - [02/Jul/2013 17:44:32] "POST /channels/504/tune HTTP/1.1" 200 29 0.0030

This is the request in which is tells channel 504 to TUNE, i.e., starts up an ffmpeg process that begins to consume the hdhomerun stream from channel 504 and begins an HLS transcoding session.

127.0.0.1 - - [02/Jul/2013 17:44:32] "GET /channels/504 HTTP/1.1" 200 2406 0.0047

This is the request in which it's asking the server if the stream is ready to be consumed yet. Once it is, it'll reveal the video player and start playing the m3u8 url.

127.0.0.1 - - [02/Jul/2013 17:44:32] "GET /channels/504.m3u8 HTTP/1.1" 404 - 0.0014

This is the request in which the stream is actually beginning to be consumed.

SOOO.... what's weird is that it only checks the status once before it starts to play. it takes about 10 seconds for the stream to be ready, so there should be a lot of requests before it tries to play. If you could try to do this yourself and post the results of the requests, that'd be helpful.

[maddox]

Ok, check out #4. It's already been merged. This should make Wallop work more like you'd think it should work. IE, if you open a channel URL, it should start the tuning/streaming process.

Just pull down the new code and restart the server. I'm not sure if this will fix the problem, but it will at least be more obvious in what is happening.

Report back on what happens after this new stuff.

[tinycg]

While that update helped, it got me debugging and realizing that the ffmpeg command you were running as a default I didn't have some of the libraries. I've now installed those and everything seems to be working.

I'll have to look into some tweaks because cutting that many ts files seems to slow a few things down for me until it gets going? Seems like it has some lag for the first minute and I think its related to that.

Where in the example are you cutting the TS files, I couldnt find it, is that part of the ffmpeg string?

[maddox]

I'll have to look into some tweaks because cutting that many ts files seems to slow a few things down for me until it gets going? Seems like it has some lag for the first minute and I think its related to that.

Yes! The first minute or so of streaming can actually go slow. It will start streaming, then buffer a couple times, but once it's been streaming for more than about a minute, everything is fine. I'd love to figure out why exactly it's doing this.

Where in the example are you cutting the TS files, I couldnt find it, is that part of the ffmpeg string?

FFMPEG is handling all of it.

[maddox]

My experience is that streaming starts in about 10 seconds, the video plays for about 15 seconds and then buffers, starts again, plays for about 30 seconds, buffers again, then starts playing fine and is good to go for the rest of the session.

We could bump the time of each segment to 10 seconds, but it means a starting buffer time of about 40 seconds since the m3u8 playlist won't be generated until there's a couple segments in there.

The ffmpeg command can be found here: https://github.com/maddox/wallop/blob/master/lib/wallop.rb#L17

[tinycg]

Thanks maddox, I'll play around a little bit. This is awesome, having tried unsuccessfully to hack EyeTV with a new lib a year ago to work with the Prime to attempt to get CC channels. It was tricky and I almost had it until I hit a few roadblocks.

This is the exact kind of API I was hoping was under the covers of something like EyeTV, very slick.