Created attachment 205442 [details] [review]
av-cp: Don't create an enless loop

Review of attachment 205442 [details] [review]:

ACK!

Hm, wait. That breaks the "TotalMatches = 0" case. Back to drawing board.

Actually it looks like av-cp doesn't really handle the "TotalMatches = 0" case properly at all.

Created attachment 207245 [details] [review]
av-cp: Don't create an enless loop

If the server reports a total_count > 0 but smaller than the returned
children so far, av-cp would enter an endless loop since the unsigned
integer substraction ended up in a rather large remaining number of
items to be fetched.

Still behaves weird :-/

What should be a correct behaviour when TotalMatches=0 ?
Looks like it is allowed by the spec.

There are couple of conditions with TotalMatches=0:
a) RequestedCount = NumberReturned -> possible more items
b) RequestedCount > NumberReturned -> no more items
c) RequestedCount < NumberReturned -> broken server

My thinking is that for b and c CP doesn't call Browse any more.
For a, cp should Browse again until NumberReturned = 0.

---
ContentDirectory:4 Date: December 31, 2010
Service Template Version 1.01 section 2.5.7.2 Arguments, says:

If the ContentDirectory service implementation cannot timely compute the value of TotalMatches,
but there are matching objects that have been found by the ContentDirectory service
implementation, then the Browse() action MUST successfully return with the TotalMatches
argument set to zero and the NumberReturned argument indicating the number of returned objects.
If the ContentDirectory service implementation cannot timely compute the value of TotalMatches,
and there are no matching objects found, then the Browse() action MUST return error code 720.

The way I'm doing it in Helium seems to work quite well: 

https://github.com/phako/Helium/blob/master/upnp/browsemodel_p.cpp#L423

Patch commited and I can't reproduce the weird issues anymore (actually it's already released in 0.8.5)