I made two other tests today. In all previous tests the PMS server and the ATV were connected to the same router (PMS with a 1,5meter ethernet cable, ATV with a pair of PowerLine adapters). In these new tests I've connect the ATV to the router with a 1,5m ethernet cable, therefore the powerlines were removed from the path.
The result is that the problem still appears, but it appears earlier than before (one test in chapter 7, another in chapter 11). All previous tests showed the problem on chapter 16 or after (typically between chapters 22 and 24).
It looks like that, the faster the connection, the earlier that the ATV enters the buffering state. My router does not support MTU parametrization, that is the next thing I would like to do, there is a number of posts in other forums saying that the ATV3 may enter in buffering state unless MTU is set to 1500 (I have it set to 1500 in the PMS server, but not in the router).
Another test this morning, this time with a different setup:
PlexConnect (Feb/23 version) installed in the Syno (ds411slim), ethernet connection to ISP router (port 1)
PMS1 0.9.11.7 installed in the same Syno as PlexConnect, same ethernet port as above
aTV3 Rev. A with firmware 7.0.3 (equal to prevous tests), ethernet connection to powerline adapter, connected to ISP router (port 2)
iTunes 12.1.1.4 installed on Win7 PC, wifi connection to ISP router
PMS2 0.9.11.7 installed on Win7 PC, same wifi connection as above
3 copies of the test file (PMS1, PMS2 and iTunes)
I've tried to collect more info about the problem, so I've played 10 seconds from iTunes, then moved to PMS2 and played another 10 seconds. Everything was Ok. Therefore I've started the test film from PMS1 and waited until the problem appeared.
This time, unlike others, I was near the TV and my computer, with the graphical activity monitor of the Syno always visible. It showed LAN activity, but suddenly it stopped and 5 minutes later the aTV3 entered the buffering state. During these 5 minutes the aTV played Ok, but there was absolutely none LAN activity.
Then I made the following tests with the aTV:
Navigated out of PlexConnect and selected YouTube. No thumbnails were available. All I had in the screen were black rectangles with some text below. I've selected one video at random and it played Ok
Navigated out of YouTube and entered iTunes. No thumbnails available. I've selected a film but the play never started because the aTV entered the buffering state
Navigated out of iTunes and entered PlexConnect and PMS2. No thumbnails available. I've selected a film but the play never started because the aTV entered the buffering state
Stopped PMS1, started PMS1, navigated out of PMM2 and entered PMS1. No thumbnails available. I've selected a film but the play never started because the aTV entered the buffering state
Restarted aTV, navigated to YouTube, iTunes, PMS1 and PMS2. All thumbnails appeared, I've played 10 seconds of a video from all these 4 sources, all played Ok
Unfortunately I did not have loglevel high / debug / verbose to post here, but based on this test, I had a second look to logs of test6 and found, in the PMS log, several "ERROR - Error writing media: 32 - Broken pipe" messages, the last one +/- 6 minutes before the aTV entered in buffering state.
The PlexConnect log test6 shows nothing between film start and end times. But PlexConnect is reporting activity to PMS, and PMS is recording such messages in its log (last week I've modified PlexConnect for a 60sec cadence, instead of 5sec, but that showed no effect on the problem, although it produced a different log in PMS, but since then I've returned to a "clean", not modified PlexConnect code).
Once you start playing media Plexconnect is not actually used, it's PMS to aTV which is why there is nothing in the Plexconnect log.
I was convinced of that, but that's not entirely true. if you go to application.js (line 60 in the current version of it) you will see that PlexConnect is reporting progress activity to PMS every 5 seconds.
Yes I guess that’s part of Plexconnect, but the JavaScript is actually running in the ATV and that’s the scrobble so pMS knows where to save view state
Thanks, this gives me one idea -> when I made a test with iTunes I did not have progress tracking active and buffering never appeared, I will repeat the tests with progress tracking active in iTunes to see if the buffering shows up.
Edit - played one time from iTunes without buffering problem, playing a 2nd time to confirm
I got my hands on a few more aTV's for dirt cheap and will try to do some testing when I find some time. One of them are on iOS 7.0.3 aTV3 (not a rev a). I wonder if the PlexConnect host is possibly the culprit hardware wise just not having the ability to get it done. Im just curious why your 576p file is doing that to you when my issue was only during large resolution files (e.g. 1080P).
I wonder if the PlexConnect host is possibly the culprit hardware wise.
It's possible, if I run out of ideas I will install PlexConnect on my Win7 laptop to test. With PlexConnect in the Syno and PMS in Win7 the problem still exists.
I've noticed that the java code in PlexConnect 0.3.1 is much smaller than in recent versions, so I've setup another test environment with PMS 0.9.11.7 and PlexConnect 0.3.1. Since Java is running in the aTV there is a possibility that this is causing the problem...
Edit - buffering problem also ocurs with PlexConnect 0.3.1 + PMS 0.9.11.7
Edit 2 - buffering problem also ocurs with PlexConnect 0.3.1 + PMS 0.9.9.10
Conclusion: from now on I will use recent versions of PMS and PlexConnect in my tests, I cannot afford, even for a small library like mine, to rebuild it whenever I change a PMS version (to start from a "clean status").
One more test, one more "buffering situation". This time I've made the following:
Start playing the test film
Stop PlexConnect
Waited until buffering problem started
The test film played Ok with PlexConnect stopped, and at chapter 20 the buffering situation started. Skipping to another chapter was not possible. I think that this rules out wahlman.j's hypotesis that PlexConnect host could be the problem.
In the PMS log there are several "Error writing media: 32 - Broken pipe". Looks like, at the time of failure, the cadence of these errors increased from a 5-6 second average to a one second average. Could it be that PMS decided to query the aTV more often to capture the playback time, and this caused some sort of overrun in the aTV ?
Then I reboot aTV and continued to play the film. Stopped PlexConnect. Skip to other chapters is possible (previous or next chapters) with PlexConnect stopped.
I've been using the PlexConnect sub-forum to report the problem, but more and more this looks like a PMS problem. Where / how can I report it ?
I’ve been following this thread as I appear to have the same issue. What I discovered tonight is that the problem only seems to exist over ethernet. When I swithed to wifi I could not reproduce it. Did you try wifi by any chance?
I've been following this thread as I appear to have the same issue. What I discovered tonight is that the problem only seems to exist over ethernet. When I swithed to wifi I could not reproduce it. Did you try wifi by any chance?
Thanks for your suggestion. I will test with wifi and report the result. One of my earlier tests was connecting PMS and ATV with ethernet cable to ports of the same switch, and apparently the buffering started earlier than when both devices were connected to ports of the same router, suggesting that the faster the connection the earlier the buffering, but this is just an idea, I have no evidence to prove this.
Interesting. I know there have been other reports of flakely ethernet connectivity on the ATV especially on more recent updates. I'd have to search for the specific posts. Not necessarily in the context of plexconnect. Maybe there is something funny about PMS->ATV that triggers this issue with ethernet. I did also test with ios plex airplay to ATV and had no issue. I know it's variable depending on app but i thought most apps hand off the stream directly to the ATV so this should be a similar scenario to plexconnect once the video is started but yet it doesn't occur. I'm not smart enough to figure this out but maybe this info is helpful to you or others.
At some point in time I've tested, with exactly the same connection type (server and aTV connected to ethernet ports of the same router), the test film with iTunes and with Plex. I had the buffering problem with Plex but not with iTunes.
Would it be possible to modify the javascript code of PlexConnect so that communications between PMS and aTV are slower ?
Restored ATV to firmware 7.1 (7003) - the buffering problem still exists
Changed TV Resolution to 720p HD-50Hz (it was Auto) - the buffering problem did not appear after one play
I leave in a Country where electricity is 50Hz. For some strange reason the TV Resolution=Auto resulted in the ATV thinking that 720p HD-60Hz was the correct setting for my TV. Changing it from 60Hz to 50Hz seems to have solved the problem. I will try to play the test film a couple more times to be sure and report here.
Restored ATV to firmware 7.1 (7003) - the buffering problem still exists
Changed TV Resolution to 720p HD-50Hz (it was Auto) - the buffering problem did not appear after one play
I leave in a Country where electricity is 50Hz. For some strange reason the TV Resolution=Auto resulted in the ATV thinking that 720p HD-60Hz was the correct setting for my TV. Changing it from 60Hz to 50Hz seems to have solved the problem. I will try to play the test film a couple more times to be sure and report here.
Just FYI, your TV does not need to be set at 50Hz because of electricity. Those two frequencies are not related.
Just FYI, your TV does not need to be set at 50Hz because of electricity. Those two frequencies are not related.
Thanks for the info. I guess I spoke too early. The buffering started @ chapter 19 of the 2nd play. This particular film is coded at 25fps, and it looks like changing the aTV Resolution from 60Hz to 50Hz delays the problem. In other words, with TV Resolution=60Hz (and ATV / PMS connected to the switch) I get the buffering problem after +/- 30 minutes, with 50Hz it appeared after +/- 4 hours
Edit - When I got buffering after 4 hours, it was precisely when I tried to open PlexWeb in my iPad (using Safari). There is an error in the PMS log "ERROR - handle_stream_read error 2 End of file" that never appeared before, and is probably caused by that failing attempt to use PlexWeb. Therefore I've initiated a new series of tests with TV Resolution=50Hz.
After 3 consecutive plays of the test film (+/- 8 hours) with TV Resolution=720p 50Hz (instead of 720p 60Hz) no buffering was observed. Problem solved !
After 3 consecutive plays of the test film (+/- 8 hours) with TV Resolution=720p 50Hz (instead of 720p 60Hz) no buffering was observed. Problem solved !
This isn't really a fix if you want to use the the ATV3 as intended which here in the US is 1080p 60Hz. However after the 7.1 update I retried ethernet and a video that typically reproduces the buffering by 30 minutes in and I got about 1hr 30min in with no issue. Had to stop it early to watch a show. Will need to test more but it's possible ethernet issue is fixed in 7.1 firmware. Will update after more testing.
This isn't really a fix if you want to use the the ATV3 as intended which here in the US is 1080p 60Hz. However after the 7.1 update I retried ethernet and a video that typically reproduces the buffering by 30 minutes in and I got about 1hr 30min in with no issue. Had to stop it early to watch a show. Will need to test more but it's possible ethernet issue is fixed in 7.1 firmware. Will update after more testing.
My test film had 25fps. What is the fps of the film that usually gives you problems ?
Anyway, after you have discovered that the buffering problem does not exists with wifi I read a little bit about DASH streaming. A recent PMS version, available to you (you have Plex Pass) but not yet to me mentions improvements in DASH streaming. Could a permanent solution be provided by this new PMS version ?
My tests with firmware 7.1 and PMS 0.9.11.7 showed buffering when I had TV Resolution @ 60Hz, I saw no improvement over 7.0.3 in that respect.
