Beta version details
2.0 beta 8 (17-Aug-2017)
- Live streams support
- Video visualization
- Improved feeds support
- External metadata storage
- Metadata construction changes
- Sharing for files being currently downloaded
- Shortcut files support
- Technical changes
- Back compatibility
- Other changes
Temporary placed here to make it easier to track the changes between beta versions.
Beta 4. Initial public release.
Beta 5. Support decoding and info read for tracks without custom URL scheme. Fixed incorrect behavior of Enter key in search results list. Fixed metadata filling for tracks coming from search popup window. Corrected support of fy+file scheme.
Beta 6. Restored missing labels for controls (screen reader). Added Replaygain support in track properties storage. Also now component will retain info and metadata managed by 1.x version. Updated ffmpeg to 3.3.3.
Beta 7. Added
Columns popup menus to context menu of search results list in search popup window. Fixed lack of clips duration in that list. Adapted that context menu for screen readers. Fixed intermittent failure to start video playback. Fixed search-related context menu items and a crash causing by
Make Album menu item.
Beta 8. Metadata overriding now is also possible for tracks representing feeds. Metadata editing now is possible for everything (regular tracks / feeds; with / without metadata overriding; shortcut files), exception - tracks representing search, if they are not coming from shortcut files. Fixed possible hang in album art provider.
While that was started (more than half year ago) with clear intent to add support for live streams and few other things, with the time it became comprehensive rework, refactoring and rethink of the component.
After closer meet with chunked streams (both HLS and DASH) shy hopes to eventually separate component to few ones (site analysis, video, utilities) were ruined because that would require either code and functionality duplication or rich SDK to handle various aspects of data access. Not enough time and patience for second option, but enough conscience not to choose the first one. With that said, there was chosen third option: do one's best within single component. Not elegant, but functional. After the choice was made, everything became simple and started to develop rapidly. One thing was triggering another, and so on.
At first there will definitely be some issues. Please, treat with understanding and notify about everything that does not seem to work properly and is not stated below to been changed.
Live streams support
It finally has been added to component. Currently only for Youtube.
For now video works only when
LAV Splitter is selected in component preferences
Video Media downloading. There are also problems with video+audio synchronization.
Youtube Video item from menu
View Visualization now became just
Video. Treat it as a visualization that can play some video for currently played track. It is possible, but not necessary, to use video
from the same file where the audio comes from.
Previous behavior (to play videos only from supported sites) can be brought back using advanced preferences
Video Allow video playback only for supported URLs.
Improved feeds support
Work with the feeds now is performed in a different way. Visible change in this regard - when adding Youtube feed (i.e. channel or playlist) using menu
File Add location... now will be added one track representing this feed, instead of retrieving content of the feed.
Internally the change was to make the feeds to behave like any other tracks. This will make it possible (in future) to search for feeds and to list playlists that channel consists of when it is being added (instead of retrieving videos from 'Uploads' playlist of this channel, as it is done now).
External metadata storage
In 1.x version metadata was getting lost once the track was removed from playlist. That was because metadata and clip properties (description, view count etc.) were stored in track tech info, an internal storage associated with the track. So this storage existed only while track was in the playlist.
Now for the clip properties and metadata edits is used external storage (local file system at this moment). Note, tech info is still used as intermediate storage, so the issue with limit of custom metadata fields length is still there (e.g. description gets clipped and appended with
(...) if it is longer than maximum length of tech info field).
Metadata construction changes
Now component maps existing clip properties to metadata instead of developing metadata out of the title.
That is about clip title parse rule. The problem with it is that if you listen the music, it works mostly but not always. If you listen something other than music, it just does not work, making a mess in regular playlist view setups. With that said, it just cannot be default option for metadata construction. New approach is an attempt to make the clips and feeds to look more consistently in regular playlist viewer configurations.
For tracks representing video clips new approach is straightforward: use uploader as %artist% and full clip title as %title%.
Similar thing is done for tracks representing the next portion of the feed ('get more' items in 1.x version). There are more metadata fields developed out of info available from these tracks:
|Metadata||Info about search portion||Info about playlist portion|
|%title%||search query string||playlist title|
|%album_artist%||"Youtube"||title of the channel where this playlist comes from|
|%tracknumber%||index that would have the first clip obtained from this portion of the feed|
|%totaltracks%||number of search results||number of clips in the playlist|
|%discnumber%||index of this feed portion, like page number for search results on the site|
|%totaldiscs%||total number of feed portions|
|Additionally track duration represents number of items in this portion, one second equals to one item. Well, it is more convenient than it sounds.|
If one would like to bring back behavior from 1.x version, it can be enabled using option
Enable clip title parsing rule from
Features tab of component preferences. Note, to update info for already added tracks in this case (as well as after rule edit) now need just reload track info (e.g. using context menu
Properties Metadata Tools Reload info).
Sharing for files being currently downloaded
There can exist several readers at the same time (for audio playback, for video playback, RG scanner, Waveform Seekbar etc) and in 1.x they were initiating individual separate download even if the source file was the same. Now they will use single instance of the file, reducing bandwidth usage.
Previously, to somehow mitigate this need to start several downloads, audio quality settings were divided to settings for playback and 'for other', i.e. anything not related to playback. And quality 'for other' was set to lowest possible. This possibility is retained, but quality 'for other' now is defaulted to the same quality as for playback.
Shortcut files support
These are textual files that behave like shortcuts for the clips. Pretty like m-TAGS, but is designed specifically for the component needs. Note, since feeds are represented by single items now, these files can also point to the feeds, i.e. it is possible to make shortcuts for Youtube playlists or for search.
Well, that one came almost for free, since it is used internally by metadata and properties cache implementation, so why not.
File extension is
*.foo_youtube (no imagination). As an example can be used cache files located at
<fb2k_config_dir>\foo_youtube\cache\meta\. Reference documentation is not prepared yet.
Custom URL scheme used by component was changed. There was three problems with the old one: it did not conform RFC (started with a number); I never liked it; and (this is what triggered the change) it did not retain original URL scheme. Now this is important, scheme should be retained. So custom URL scheme now is
fy+file. Full URL example:
Tracks representing the feeds are special. They have scheme
fy+search for search,
fy+playlist for playlists, and in future will be added
fy+channel for channels.
In 2.x was removed possibility to switch between built in decoder (which uses ffmpeg) and decoding provided by foobar2000 core. There do not seem to be any advantages in context of this component to use both of them. Internal decoder is the must to have chunked streams support. And with possibility to select external ffmpeg binaries it brings additional direction for experiments. So it is the one that stays.
So, decoding is done entirely by ffmpeg. Data access is handled by the component, bringing possibility for shared access (described above) and caching (in a distant future).
When a track is added with
fy+ prefix in the URL scheme, component does not check, whether it points to the supported site (or to site at all), and just does its best. In other words, it is possible to play regular files, local or remote. Side effect, that was possible to develop without too much additional effort. Note, embedded ffmpeg has support only for media formats and audio decoders commonly used on online media sites. I.e. formats: mp4, webm, 3gp, mpegts (hls); decoders: aac, opus, vorbis. So you may need to setup external ffmpeg for that. For example, the one that is shipped with LAV Filters can be used.
Live streams support is available only for HLS streams (ffmpeg does not support chunked DASH). Stream selection is handled by the component (according to appropriate quality settings).
Now all Internet access is performed either using foobar2000 API or internally by the component (related settings previously controlled only media files downloading).
Support for old custom scheme is fully retained. For the clips that were already added to playlist, initial info read will move everything (custom metadata, clip properties, replaygain) to new location. That move is not back compatible.
Support for old custom scheme used for 'get more' items was not retained.
Possibility to override clip title parsing rule via URL param was not retained.
Custom metadata prefix was changed to
fy_. Few fields were added, few renamed. Briefly, full list is:
%fy_title%, %fy_description%, %fy_uploader%, %fy_published_at%, %fy_view_count%, %fy_like_count%, %fy_dislike_count%, %fy_rating%, %fy_like_ratio%, %fy_channel_url%, %fy_thumbnail_url%.
- menu item
File Add multiple URLs...was moved to its own popup menu to not confuse it with standard foobar2000 functionality
Add titles...was separated from
Add multiple URLs...for consistency. It also got additional functionality (configurable number of tracks per title and whether to add item for next search potion)
- context menu item
Copy URLnow works for multiple items. Comparing to simple copy of track path, it additionally strips metadata overriding params from URL, correctly restores URLs for tracks representing the feeds and copies origin URL for shortcut files
- now it is possible to set multiple values for metadata tags
Changelog Beta version details