View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014403 | MMW 5 | Playback | public | 2017-09-20 21:12 | 2017-10-07 01:00 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0014403: Initiating of cloud playback takes long time | ||||
| Description | Trying to play a song from cloud (OneDrive, DropBox, Google Drive, Google Play Music) takes 10 or more seconds before the playback actually starts! To be found why as the stream link is get in second so there must be something bad in the playback starting code. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2079 | ||||
|
|
Much improved in 2079 (playback mostly starts in less than second now) |
|
|
Re-opened: One of the changes (in in_wmp3.dll) caused a regression. Seeking does not work correctly. |
|
|
The seek regression is fixed, but it pro-longed the playback start time from 1 to 2 seconds because WM (Window Media core) seeks also file end before playback start (for last 128 bytes -- ID3v1 tag) which initiates another HTTP range request. To find whether there is a way to force WM to skip the ID3v1 tag read, alternativelly we could use in_mfaudio.dll (using Media Foundation), but there are also some issues: - MM gives the stream url directly to MF so it cannot be used for links that needs authorization (currently Google Drive links) - MM performs additional short HTTP request to detect stream type to find whether it isn't ALAC to prevent from freezing observed by Rusty, details here 0008577:0028542 |
|
|
As discussed offline, another way is to hack in_wmp3.dll and supply "fake" ID3v1 to WM (without initiating the needless stream seeking). Assigned to Michal to implement this "hack" in in_wmp3.dll |
|
|
Fixed |
|
|
Verified 2080 |
