Closed sidevesh closed 8 months ago
sidevesh
commented
8 months ago Its the POST request to /feedback endpoint that seems to return 500 and break playback,
this seems to be something that some of these airplay implementations do to maybe keep alive connection:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3279#note_2056968
If this endpoint is of no use for AirConnect then can it be added just so we don't send a 500 causing the playback to stop ?
philippe44
commented
8 months ago I'll do a 501
philippe44
commented
8 months ago Can you tell me if this works aircast-linux-arm.zip
sidevesh
commented
8 months ago I think you will to return a 200 here so that the server does not fail https://openairplay.github.io/airplay-spec/audio/rtsp_requests/post_feedback.html https://emanuelecozzi.net/docs/airplay2/rtsp/
It seems to be just a heartbeat check to see if client is still alive
philippe44
commented
8 months ago AFAIK it's an AP2 feature, so responding "not implemented" seems appropriate where 500 was not, I agree. If a server fails on a 501 on hearbeat, knowing this is an AP2 command, then that server should be corrected
sidevesh
commented
8 months ago still breaks, can you give me a binary that responds with 200 just so I can test it and then raise the issue with pipewire maintainers regarding /feedback being AP2 feature.
Seems like this /feedback endpoint usage is something other tools like atv for python also do, so this is not limited to just pipewire.
progress: 0/0/0
[I][09280.470364] default | [ rtsp-client.c: 246 process_status()] status: RTSP/1.0 200 OK
[I][09280.470540] default | [ rtsp-client.c: 322 process_header()] Audio-Jack-Status: connected; type=analog
[I][09280.470565] default | [ rtsp-client.c: 322 process_header()] CSeq: 5
[I][09280.470583] default | [ rtsp-client.c: 279 dispatch_handler()] received reply to request with cseq:5
[I][09280.470600] mod.raop-sink | [module-raop-sink: 952 rtsp_log_reply_status()] reply status: 200
[I][09280.512285] default | [ rtsp-client.c: 246 process_status()] status: RTSP/1.0 200 OK
[I][09280.512398] default | [ rtsp-client.c: 322 process_header()] Audio-Jack-Status: connected; type=analog
[I][09280.512410] default | [ rtsp-client.c: 322 process_header()] CSeq: 6
[I][09280.512419] default | [ rtsp-client.c: 279 dispatch_handler()] received reply to request with cseq:6
[I][09280.512432] mod.raop-sink | [module-raop-sink: 952 rtsp_log_reply_status()] reply status: 200
[I][09282.423358] default | [ rtsp-client.c: 414 flush_output()] sent: POST /feedback RTSP/1.0
CSeq: 7
Client-Instance: F22F7C8FB283E6B8
DACP-ID: F22F7C8FB283E6B8
User-Agent: PipeWire/0.3.81
Session: DEADBEEF
[I][09282.439237] default | [ rtsp-client.c: 246 process_status()] status: RTSP/1.0 501 Not Implemented
[I][09282.439273] default | [ rtsp-client.c: 246 process_status()] status:
[E][09282.439338] default | [ rtsp-client.c: 470 on_source_io()] 0x55b5538db210: got connection error -71 (Protocol error)
[E][09282.439351] mod.raop-sink | [module-raop-sink: 1620 rtsp_error()] error -71
[I][09282.439390] mod.raop-sink | [module-raop-sink: 1613 rtsp_disconnected()] disconnected
[W][09282.444938] mod.raop-sink | [module-raop-sink: 506 flush_to_udp_packet()] error streaming packet: -9
[W][09282.450226] mod.raop-sink | [module-raop-sink: 506 flush_to_udp_packet()] error streaming packet: -9
[W][09282.460890] mod.raop-sink | [module-raop-sink: 506 flush_to_udp_packet()] error streaming packet: -9
[W][09282.466242] mod.raop-sink | [module-raop-sink: 506 flush_to_udp_packet()] error streaming packet: -9Can you give me a binary that returns 200 OK please ? Looks like that solved the issue for shairport-sync
philippe44
commented
8 months ago We know for sure that a 200 will work but I will not do that. I put a note on https://github.com/mikebrady/shairport-sync/issues/1745 expressing my position. The heartbeat has been a known issue for a long while and I, like others, used an existing feature like requesting an "OPTIONS" to deal with it. A controller that sends AP2 request when it knows it is AP1 player shall not expect a 200.
sidevesh
commented
8 months ago @philippe44 looks like the 500 error is not the cause of my issue but something else, I have shared the logs and info related to it at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3566
sidevesh
commented
8 months ago @philippe44 https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3566#note_2125636 Does this seem to be something that could be happening with AirConnect ?
philippe44
commented
8 months ago Yes, this one is probably on me, an error when sending no header. Can you try 1.2.4?
sidevesh
commented
8 months ago Sure, I dont see it in Releases though, where do I get it from ?
philippe44
commented
8 months ago sidevesh
commented
8 months ago that fixed the issue!
sidevesh
commented
8 months ago I guess this issue can be closed as 500 error is anyways not an issue, thanks for all the help!
Airconnect seems to be failing to play for more than 1 second when I try to play from my linux laptop with pipewire's built in airplay support, things are working well from MacBook, looks like airconnect can't handle some request and returns 500 breaking playback: