GNOME Bugzilla – Bug 676684
force client disconnection if rtsp-media is in error state
Last modified: 2012-08-29 23:11:05 UTC
Usually, when GstRTSPMedia receives an error message, it will receive an EOS after it. The client will also receive EOS. However, the client could ignore the EOS and not close the connection to the server. This means the session would still be running as well as the media which is in the error state.
Created attachment 214809 [details] [review] close client connection if media in error state This patch closes the client connection if media is in error state, and solves the mentioned problem.
This patch is not quite right. It would disallow a client to request a new media (if the old one was in error) You probably want to hook somewhere after the calls to find_media() and stop if the media was in error.
Created attachment 214890 [details] server with client ignoring EOS I attach a log file where the client ignores the EOS and thus not disconnects from the server. I have also found a workaround to my problem. A brief description: - media is shared. - media source is a shmsrc made available when "something happens". - problem occurs when shmsink (in another app) is cancelled and the client does not disconnect. media not unprepared. - if source is available again (something happened again), as media is shared and client is connecting with same URL, the old media is used again. However the old media still has the old shmsrc (with old socket-path). The workaround is in factory gen_key. I create a different key if the source is different, even if the same URL has been given. However, the first client is still connected and the first media will not be destroyed until that client disconnects. I don't know how to solve this except with my first patch.
This was not actually a bug in gst-rtsp-server and can be fixed from the application, so marking this bug as invalid.