View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012524 | MMA | UPnP / Casting | public | 2015-01-22 15:32 | 2015-06-10 19:53 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.1.0 | ||||
| Target Version | 1.1.3 | Fixed in Version | 1.1.3 | ||
| Summary | 0012524: UPnP Buffering results in incorrect playback stats | ||||
| Description | Using UPnP with with an MMW server causes the playback stats on the server to be incorrect in a couple of ways: 1) When a track plays, the following track is pre-buffered in its entirety. This (once 90% of the track has been loaded) causes MMW to advance the play counter. It would be preferable if MMA only loaded part of the track (e.g. 50% in advance)--that way we can avoid scenarios in which a track stats show the track as played even when the user hasn't started it. 2) If the end of the NP list has been reached, the MMA buffers the tracks from the beginning of the playlist even if Continuous mode isn't enabled. This should be fixed. The above changes won't completely solve the innaccuracy of play stats/history over UPnP (i.e. stopping playback partway through a track will probably still result in that track still being considered by MMW as played), but it will at least resolve a couple of the worst issues. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=78440 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 450 | ||||
|
|
re 2) Fixed in build 1.1.2.450 re 1)It's not possible to control it on MMA side, what about on MMW side? |
|
|
re 1) MMW cannot know whether the track will be played or skipped (once it is buffered). I am just wondering why MMA pre-buffers the next track? Most of the DLNA clients buffers just part of the currently played track, it does not make sense to buffer whole track especially when the track is long or large (hundreds of megabytes etc.) |
|
|
1) This issue is caused by gapless/crossfade playback, because next player must be prepared and set to current player. Buffering proceeds in OS layer, so I can't control it, but listener notify me that just about 5-10% of next track is buffered. Anyway I have added new option "Crossfade type: (None/gappless/crossfade)" to Options and user can change it. When crossfade type is "None", this issue doesn't occur. Fixed in build 1.1.3.450 |
