What would you like to see in VDH?

[Wild Willy]

I'd like to collect people's ideas in one place. Maybe this can be a bit of a nudge for
Michel. These are the things we'd like to see in VDH. Perhaps this can convince you
these things are worth working on:

- No more separate video & audio. (I think you are working on this, aren't you?)
- Support subtitles/captions.
- Support Vimeo so people don't have to jump through the hoops we talk about here:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/sNfTCMYfiTU

- Don't leave management of the moov atom to the operating system paging algorithm.
- Support regular DASH in addition to the mutant, proprietary variety on YouTube.
- Make it so there is no need for the HLS as M2TS setting. Just handle those cases
properly without user intervention.
- Really ignore Timed_ID3 data, including when there are multiple Timed_ID3 data Streams
within a single Program.
- Detect DRM & don't even list any variants when DRM is in place.
- Look into the issue of downloads from YouTube not working when you log in with a paid
ID, but they work when you log out.

It would also be nice to hear what you are in fact working on. Do you have even a vague
timeline in mind for releasing whatever it is you are working on? Do you have some ideas
of things you'd like to put into VDH?

And users. What do you want to see? If certain features I've mentioned are ones you
want, say so. Make this like a sort of ballot. Vote on what you want. Let's find out
what would be popular. Of course, add your own ideas, too.

[Wild Willy]

- Debugging instrumentation

Generate an activity log analogous to what ffmpeg does. That way, when we have a
problem, we can have a chance of figuring out for ourselves what might have gone wrong.
If we can't figure it out, we can send you the log & you can properly diagnose what
happened. You might discover bugs you can fix. You might discover additional debug
logging you should be generating. You might suddenly be able to diagnose problems on
paid sites where you (justifiably) refuse to subscribe yourself. If a user enables this
logging, do not take a default destination for the log. Force the user to supply a
destination directory at least the first time. If this setting somehow gets cleared at
some point, prompt again. Don't make it easy for users to unsuspectingly pack yet more
bloat into their boot partitions. Include in each debug log these minor bits of
insignificant information: operating system, browser & release, VDH release & whether
it's licensed, CoApp release. The logging would include any URLs being downloaded from.
Gee. I wonder where I got this idea from. Could I be automating the task of supplying a
proper problem report? What a concept . . . Always generate these logs. A user can't
know ahead of time that a problem is going to occur. So always generate these. Then
have the user set some threshold for the number of logs to keep & delete the oldest one
at the threshold when you are about to create a new one. A debug log should be per
download, not per browser session. I imagine a threshold of 5 or 10 should be good
enough.

- Persistent history

You & I have already discussed at length why VDH cannot resume a failed download from the
point of failure, neither automatically nor manually. But when there is a failure, we
have to either scrape our recollections to reconstruct what might have been lost in a
crash, or use manual techniques to track our activity externally to VDH. Help us.
Create a persistent download log. The entries should give these data items:
. URL of web page
. target drive:\directory tree\file name for the download
. date/time download started
. date/time download completed with status (success/failure)
. depending on how fancy you want to get, calculate final target file size divided by
elapsed time of download to give average speed of download
The log entries without a completion or with a failure completion would be the ones we
would need to start over. Leave it to the user to remove log entries. The idea would be
oh, I remember that one. It finished fine & I can now delete this log entry. Oh, that
one failed. I forgot about that. I'll run that one again, but I'll delete this history
entry now so I don't get confused. This history should persist across browser sessions.
Don't take a default for where this history log should reside. When you implement this,
have first-time logic to make the user supply a destination directory for this. And if
this setting somehow gets deleted, prompt again. That way, there will be no excuses for
a user not knowing this logging is going on. On browser launch, you should float up a
timed notification saying how many history log entries currently exist. Force the user
to think about this.

[FFreestyleRR]

Nice topic.

I would like VHD to be able to handle DASH streams and to be as much closer alternative to IDM as possible even if a license is being required (lifetime would be better than yearly). :)

[mjs]

HLS as M2TS should be the default in my opinion, that solves the choppy video issue and audio going out of sync with video.

Mig knows there is an issue for HLS downloads but leaves this setting off.

The Vimeo problem I believe is a bug in VDH, the hit details shows the correct frame rate but still has a messed up frame rate once the file

is downloaded.

Dash is bit of an Achilles heel for VDH as the manifests don't seem to conform to one format.

Even a site like Facebook makes it hard, I don't see any manifests and the streaming urls don't distinguish between video and audio.

I don't use Facebook, i'm highlighting why it doesn't detect anything unless switching to the mobile site.

 

video

[https://video.xx.fbcdn.net/v/t39.25447-2/347430715_751010109831185_1262556976138562158_n.mp4?_nc_cat=102&ccb=1-7&_nc_sid=9c5c06&efg=eyJ2ZW5jb2RlX3RhZyI6ImRhc2hfcjJfYXZjX2dlbjFhdmNfbGNfcTYwX2ZyYWdfMl92aWRlbyJ9&_nc_ohc=yxWEy8EKe9AAX-j6gBI&_nc_ht=video.fmel5-1.fna&oh=00_AfCLRlWzUa2NSlFzGMCbwJZrbBHVaLPJoLwnf4z_3bzcSw&oe=6482D99F]

audio

[https://video.xx.fbcdn.net/v/t39.25447-2/347258185_909624276773367_6243239037584446189_n.mp4?_nc_cat=109&ccb=1-7&_nc_sid=9c5c06&efg=eyJ2ZW5jb2RlX3RhZyI6ImRhc2hfYXVkaW9fYWFjcF80OF9mbm9ybTE0X2ZyYWdfMl9hdWRpbyJ9&_nc_ohc=IUr_yHLCMmgAX97vQok&_nc_ht=video.fmel5-1.fna&oh=00_AfDoD6D_aUlC3hn-Nc_gIzyDBisMBs8V_y43BQar9Q0lWA&oe=648320FF]

[jcv...@gmail.com]

Hi Willy,

Good idea.

We will probably make an official announcement soon but things should move for VDH. A new dev has joined the team!

This is the good moment for this kind of initiative :)

jerome

[Wild Willy]

Then piggybacking on that, make VDH act internally as if HLS as M2TS is enabled all the
time. Remove the setting from the settings dialog. But don't leave the resulting file
as xxx.m2ts. Leave it as .mp4 or .mkv or .webm or whatever might be what the user is
expecting. People don't want A/V files that are .m2ts. They want something recognizable.

[Wild Willy]

A new dev. Wonderful! Might we have a name? In fact, might we have a complete list of
the names of the devs? Not trying to pry; user IDs would be good enough. I have always
thought the team consisted of Michel & that's it. Have there always been more devs on
the team? How many devs do we have now?

[jcv...@gmail.com]

No sorry, for the moment we will "protect" him ;)

But be sure he is a good one, all I can say is that he worked for Mozilla a few years.

We'll tell you more asap, promised.

jerome

[Wild Willy]

- Mouseless operation

Any power user avoids the mouse as much as he can. But VDH is impossible to use without
a mouse. Almost all functions in VDH are inaccessible except through mouse clicks. I
could catalog the shortcomings for the next 10 screenloads of this thread. But I will do
that only if the initiative is undertaken to free VDH from the tyranny of the mouse. VDH
is currently utterly pathological in the way it reacts to the arrow keys, page up & down,
space bar, enter . . . if it reacts at all. There is a conventional standard way that
Windows applications can be operated from the keyboard & VDH doesn't allow it. Thousands
if not hundreds of thousands of Windows apps allow the use of the keyboard in a certain
way. VDH should as well. I'm not talking about keyboard shortcuts or macros. I'm
talking about making it possible to operate VDH using the kind of keyboard interactions
that you can see in pretty much every other application on your system.

- Reliably terminate an inflight download

There is a Stop button on the blue dot status menu. It works sometimes & it fails
miserably other times. When it fails, you are left with a file that won't play & can't
be repaired. Well, there might be a way to repair it but I haven't tested it yet. It's
an idea that was posted by another user in the Too Fast thread. But that's not the
point. The fact is that the stop button fails more often than it works properly. This
ought to be fixed. I suspect this might be closely related to my suggestion above about
the moov atom.

- Let the user specify a certain length of time that VDH will download something, & then
terminate the download. This could be most useful for livestreams.

- Let the user specify a certain time & when the target file reaches that duration of
content, stop the download. This is different from the suggestion I just made. One
suggestion is to limit how long VDH will spend downloading something. The other
suggestion is to limit the size expressed in time of the target file. Example: I want my
target file to have duration 1 hour. VDH might download that in 3 minutes or 3 hours or
almost anything in between, depending on the level of service being offered by the
server. So I'm looking for independent controls for both those times. They could even
both be specified for the same download. Example: I want a file to be no longer than 1
hour duration, but if VDH has been downloading it for an hour & the file is still only 38
minutes long, stop anyway. On the other hand, if the file has reached duration 1 hour
after downloading for only 38 minutes, stop.

[Wild Willy]

- Restore keyboard shortcut for opening the VDH menu

VDH 8.0.0.0/8.0.0.0a2 beta lost the keyboard shortcut for opening the VDH menu.  It had always worked before but it stopped working in this release.  Michel looked into this & discovered that it works on the other platforms but it does not work very specifically in Firefox on Windows.  This needs to be fixed.  The other keyboard shortcut, for executing the default action, is still functional.

[Wild Willy]

- Support for being logged in with a paid account on YouTube

I have a free generic Google account. This gives me GMail, Drive, permission to post in
Google Groups, whatever a free account allows you to do. VDH downloads from YouTube work
the same for me when I am logged in & when I am logged out. But people with paid
accounts do not have the same experience. It seems that they must log out in order for
VDH to download from YouTube. This is not a solution. It is workaround, a workaround
that is far from optimal. VDH needs to work on YouTube regardless of your logged in
status, even if you have a paid account.

Now, I don't have one of these paid accounts so I am looking for somebody with experience
with a paid account to post here. Is there a difference between a paid Google account &
a paid YouTube account? Are there different tiers of accounts, like basic, intermediate,
& advanced, or some other terminology? What are the differences in what you can do
depending on the grades of paid accounts?

I would be surprised if Michel bought a paid account in order to investigate this issue.
So he is going to need volunteers to tell him things & test things. Here's your chance
to speak up.