Bug #340

Opening an Internet channel takes too long at the first time

Added by Maxim Khaberev about 4 years ago. Updated about 4 years ago.

Status:Closed Start date:September 03, 2013
Priority:Minor Due date:
Assignee:- % Done:

100%

Category:core
Target version:3.4.2
Affects version:3.4.1

Description

Opening an Internet Channel takes about 40 seconds at the first time. The next attempts take couple of seconds.

Bad case:
probe.c:164 [file_find_decoder]: Probing http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925.
probe.c:120 [probe_by_scheme]: Probing by scheme.
probe.c:49 [check_opened]: Opening http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925.
probe.c:164 [file_find_decoder]: Probing http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925.
probe.c:120 [probe_by_scheme]: Probing by scheme.
probe.c:49 [check_opened]: Opening http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925.
VFS: <0x128e980> open (mode r) http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925
probe.c:148 [probe_by_mime]: Probing by MIME type.
probe.c:156 [probe_by_content]: Probing by content.
probe.c:62 [probe_func]: Trying 2SF Decoder.
VFS: <0x12654e0> open (mode r) http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925
probe.c:148 [probe_by_mime]: Probing by MIME type.
probe.c:156 [probe_by_content]: Probing by content.
probe.c:62 [probe_func]: Trying 2SF Decoder.
VFS: <0x128f560> seek to 0 from beginning
probe.c:62 [probe_func]: Trying AAC Decoder.
VFS: <0x128f560> seek to 4294532224 from beginning
VFS: <0x128fa80> seek to 0 from beginning
probe.c:62 [probe_func]: Trying AAC Decoder.
VFS: <0x128fa80> seek to 4294532224 from beginning

<delay>

VFS: <0x128fa80> seek to 0 from beginning
VFS: <0x128fa80> close
VFS: <0x12654e0> close
VFS: <0x128faa0> open (mode r) http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925
VFS: <0x128f560> seek to 0 from beginning
VFS: <0x128f560> close
VFS: <0x128e980> close
VFS: <0x128faa0> close
VFS: <0x128e960> open (mode r) http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925
VFS: <0x128e960> rewind
VFS: <0x128e960> seek to 2638502742 from beginning
VFS: <0x128e960> rewind
effect.c:68 [effect_start]: Starting effects.

Next attempt:

probe.c:164 [file_find_decoder]: Probing http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925.
probe.c:120 [probe_by_scheme]: Probing by scheme.
probe.c:49 [check_opened]: Opening http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925.
VFS: <0x7fa5d4001220> close
VFS: <0x1816140> open (mode r) http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925
VFS: <0x1816140> rewind
VFS: <0x1816140> seek to 1314701345 from beginning
VFS: <0x1816140> rewind
effect.c:68 [effect_start]: Starting effects.
VFS: <0x1290d00> open (mode r) http://pub4.di.fm:80/di_clubdubstep_aacplus?40c33b9acaf24925
probe.c:148 [probe_by_mime]: Probing by MIME type.
probe.c:156 [probe_by_content]: Probing by content.
probe.c:62 [probe_func]: Trying 2SF Decoder.
VFS: <0x128ff80> seek to 0 from beginning
probe.c:62 [probe_func]: Trying AAC Decoder.
VFS: <0x128ff80> seek to 4294532224 from beginning

The issue appeared after upgrade to 3.4.1. Downgrading to 3.4 solves the issue.

System:
Archlinux x64
Web access via HTTP proxy

Associated revisions

Revision f8361b63
Added by John Lindgren about 4 years ago

When probing file content, immediately reject out-of-bounds seek requests rather than filling the whole buffer. Closes: #340.

Revision 0da1d063
Added by John Lindgren about 4 years ago

When probing file content, immediately reject out-of-bounds seek requests rather than filling the whole buffer. Closes: #340.

History

#2 Updated by John Lindgren about 4 years ago

  • Category set to core
  • Status changed from New to Closed
  • Target version set to 3.4.2
  • % Done changed from 0 to 100

#3 Updated by Michael Schwendt about 4 years ago

Is this only related to out-of-bounds seek attempts or also related to the increased probe buffer size in 3.4.1 (16K -> 256K)?

#4 Updated by John Lindgren about 4 years ago

The out-of-bounds seek attempt has been there for some time. The increased buffer size simply amplified the problem. So for this stream, where the 256K buffer was causing a 40 second delay in 3.4.1, there was probably already a 2-3 second delay in 3.4.

Also available in: Atom PDF