When Read() on the command channel failed, the buffer size was not
trimmed. Read() was never called again as the buffer appeared to be full. Fixes#322 reported by alexw.
should understand this and give precedence. For Internet streaming
it could be used by traffic shapers. Suggested by ollo@vdrportal (#237).
Modified Files:
server/connectionHTTP.c server/connectionVTP.c tools/socket.c
tools/socket.h
- Add cStreamdevFilterStreamer that is binded to current device, not channel
- new streamer can exist even when there is no active data connection (live view)
Modified Files:
server/livestreamer.c server/livestreamer.h
- Add separate data socket for sections data
- Sections data can be received when there is no active live view
(-> EPG scans etc. can be executed during replay etc.)
- regonize PUSI flag in TS packets (bullet-proof section start+end indicator)
- Use own TS buffer to read directly from socket, no need for ring buffer anymore
- Re-activate all active filters after re-connection to server
- Simplify thread start/stop/running detection to current VDR style
- Update "filter closed by VDR" detection (datagram sockets
return different errno's than pipes)
- Deliver data to first matching and active filter (do not drop data if first
matching filter has been closed, there is quite likely new filter for it)
- Add disconnect detection to avoid 100% CPU usage in cTSBuffer::Action()
Modified Files:
client/filter.c client/filter.h
- Add PAT, PMT and PCR to HTTP TS streams
- Dynamically add and remove all related pids (of channel) to TS stream
-> DVB/teletect subtitles work in clients
-> VLC can be used as client
-> HDTV (MPEG4 / H.264) streaming is possible
-> Client can select audio and subtitle tracks on the fly without re-connection -> Client can display "real" track names / languages
- Add new member function to set all pids in one shot
-> Receiver is not deleted, created and re-attached separately for every pid
(this causes discontinous start and is anyway unnecessarily)
Modified Files:
server/livestreamer.c server/livestreamer.h
- VDR 1.5.0 calls some device members in different order and
streamdev can't currently handle this.
- do not trust in OpenDvr/CloseDvr, instead keep count of active PIDs,
open data connection when it is needed and close it only when there
are no active PIDs
(closing data connection unsubscribes all pids at server end)
- some sanity checks on server side
Modified Files:
client/device.c client/device.h server/connectionVTP.c
- Use cStreamer (base class) instead of cLiveStreamer
(no need to know streamer type)
* works with cLiveStreamer and cLiveFilterStreamer
* avoid circular dependency
- visibility of cStreamdevLiveReceiver: Moved from livestreamer.h -> .c
Modified Files:
server/livefilter.c server/livefilter.h server/livestreamer.c
server/livestreamer.h
- Run section filter carbage collector when adding new filter.
Carbage collector closes all filters that have already been
closed by local VDR section handler.
(without this, closed section filters are removed only when
they receive data from server. If they wont, ...).
- Add locking to list handling (list is accessed from separate threads)
Modified Files:
client/filter.c client/filter.h
- Reset section data unpacker only after first non-full TS packet
(last TS packet of section is typically not full
- Do not close filter if socket buffer is full (EAGAIN, EWOULDBLOCK)
(closing results in 100% CPU usage in VDR section handler)
- Do not close receiving side of section pipe. Ownership of handle
has been transferred to VDR section handler when filter was opened.
Closing handle twice results closing random file handle. If this
handle is laready used by another section filter pipe (very likely),
VDR section handler CPU usage will rise to 100%.
- Move cStreamdevFilter definition from filter.h to filter.c
- Add IsClosed() and Reset() members to cStreamdevFilter:
* IsClosed() returns true if filter was closed by VDR
* Reset() discards (incomplete) queued section data
Modified Files:
client/filter.c client/filter.h
In most places casting was easy to avoid as the variables have been
casted forth and back between both data types. Anyway - the affected
functions are never used by streamdev.
