Open rtertiaer opened 3 months ago
I'm seeing issues as well testing the stream breakup branch on in house with the very old iOS test device we have. For me Airplay 1 didn't even see the amplipi device advertised.
I've seen this just ever so occasionally. What seemingly happens is that the stream never even gets to launching shairport-sync
, and silently bails early. One symptom of this occurring is a ton of messages about not being able to read the mpris data and re-launching the metadata reader ceaselessly.
I've been working on the linked branch here; I implemented logging for shairport-sync
, better process handling, and moved all the file manipulation to native python implementations. While I find it increasingly hard to replicate this problem, I am also hardpressed to believe I fixed it with any of the commits I added there, besides maybe properly killing the metadata reader on the first instance of shairport-sync?
I ran a "start and kill Airplay 1" script for 136 loops and was unable to trigger this on my branch; it's not exactly a matter of "this happens occasionally". This similarly doesn't happen when I am running a session, then stop and start a new airplay stream. It's something else environmental.
I ran the same experiment against main
, with the same result. I'm going to put my branch up for PR so that the next time this happens we have better logging and edge-cases accounted for, and then stop actively working this ticket because I haven't been able to repro this except for a ~30min stretch last week, where restarting the stream didn't fix it but restarting the box did.
During QA for 0.4.4
I found that airplay1 consistently didn't work on first attempt, but did if you closed the stream and reopened it
@LegendaryMichael / @mrahman313 did airplay 1 work well in our tests for 0.4.5?
iOS 17.5.1