Skip to main content

Notice

If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: 'Unable to open item for playback (Object not found)' with foo_input_spotify (Read 822 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: 'Unable to open item for playback (Object not found)' with foo_input_spotify

Reply #25
Minibar is blocked by foo_spotify, it doesn't allow opening decoders for any other purpose but realtime playback.
In the foo_spotify discussion article it is mentioned that the author doesn't want to actively support "ripping" tracks from Spotify (think converter).
Quote
Building the waveform afterwards from data that has been played is a possibility. I may consider looking into it if I ever get too much spare time.
IMHO you can spend that spare time in a more useful way  ;)
In theory, there is no difference between theory and practice. In practice there is.

Re: 'Unable to open item for playback (Object not found)' with foo_input_spotify

Reply #26
@Case , @Peter , just wanted to share the info I've found while debugging this issue:
`input_impl` provider is handled differently, depending on whether `Full File Buffering up` is set to a value above zero or not:
- if the value is above zero: track playback is handled as if it is added by `Add Location...`, i.e. fb2k applies some sort of internal filter on track's file path, and if said path is considered valid then `input_entry::is_our_content_type` is called, otherwise it returns `Object not found` without calling `input_impl` provider at all.
- if the value is zero: there is no filtering performed, `input_entry::is_our_path` is called directly.

Since foo_spotify stores track URI instead of URLs (to avoid breakage due Spotify URL schema change), it will cause fb2k to fail to open track when the first scenario is used.

 
SimplePortal 1.0.0 RC1 © 2008-2020