Televzr not now downloading from Vimeo?

Here's an example url -

https://skyfire.vimeocdn.com/1588007848-0x709b3072ff68555ee5b29c329c1a7640dab926ec/52b28b5b-d324-4029-b99d-3419153629d7/sep/video/72bcc7b3,7eb80ec8,d73edef6,db423a81,27985a89,2b3d774e,3721439a/master.m3u8

It offers all the available formats, but they all fail if I try to use them.

Unfortunately this is from a membership site, so you wouldn't be able to download anyway unless you were logged into the site, but it is an example of the url format I'm trying to download from.

They used to work fine, but I've tried several from the same site, and they all now fail.

Thanks, Dave.

Ok, Thanks for the information, if the problem is on our side, we will try to fix it.

Thanks Alexander.

Please let me know if I can give you any more information.

I did look in the Televzr logs, but couldn't obviously see what the problem was.

The difficulty I suspect will be finding a Vimeo link to test with which doesn't require you to be logged into a membership site.

Send the program log.

Hi Alexander, the logs are attached.

It does say at one point "requested format is not available".

This is not true, and it happens whichever format is selected (I was trying to download the 4K version).

Thanks, Dave. Logs

The video you want to download by chance is not a live broadcast?

No, the files I'm trying to download should be always available.

The download url (which I'm getting from the source code of the video page) changes every time I log on, but I guess that's normal for subscription sites. As I said, this has always worked in the past, and still does if I use VLC to download, but it no longer seems to work on Televzr.

Cheers, Dave.

We cannot reproduce the problem, we need examples of links that we can check.

Without them, we cannot fix anything.

Understood Alexander.

I will try and find a freely available link which shows the problem.

Try this one Alexander -

https://158vod-adaptive.akamaized.net/exp=1588276654~acl=%2F134886757%2F%2A~hmac=8a3b8e52c0eb0e1070c0d6c7a65288f53b4b7b62ed24f5d449ef7be0c32ca779/134886757/sep/video/398605398,398605391,398605390,398605389/master.m3u8

It's a trailer which I can download with VLC without logging into the site.

It fails on Televzr.
Cheers, Dave.

Just tried again and that link is not now working, I guess Vimeo change them all the time, even the freely accessible ones!

Unfortunately the only way I've found of getting the "master.m3u8" link which includes all the format options, including 4K, is to make the video full screen and then use Firefox's "inspect element" option to find the url hidden deep in one of the scripts.

I also have the savefrom.net helper add-on installed on Firefox, and that allows me to download all the versions from the browser anyway, EXCEPT the 4K version, which is what I want!

So I can download say the 1080p version using that, but I cannot download even that with Televzr, or any of the other formats, which is very strange!

Cheers, Dave.

Unfortunately the link is not available, we can not check.

OK, I found a page with some supposedly readily available test .m3u8 streams.

https://bitmovin.com/mpeg-dash-hls-examples-sample-streams/

This is an example that fails -
https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8

Cheers, Dave.

Ok, thanks for the info provided. We've forwarded it to developers to check and fix.

Thanks Alexander!

Hi Alexander!

Has this been fixed in the latest version, either intentionally or accidentally?

With 1.9.43@2.3.48 I can now download OK from the sources that were failing before, but now there's another problem!

The downloads now fail when they get to the very end, but only if I'm saving them on one of my drives.

The log says -

[15/May/2020:17:31:38 +0000] [error] [renderer] app:fileTransfer upnp.open error! Error [TypeError]: e.replace is not a function at Object.r.validate (file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/5c1b9231694be47cce2a.worker.js:1:221657) at file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/5c1b9231694be47cce2a.worker.js:1:49209 at D (file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/5c1b9231694be47cce2a.worker.js:1:56317) at PassThrough. (file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/5c1b9231694be47cce2a.worker.js:1:59362) at PassThrough.emit (events.js:210:5) at endReadableNT (_stream_readable.js:1183:12) at processTicksAndRejections (internal/process/task_queues.js:80:21) { name: 'TypeError', message: 'e.replace is not a function' }
[15/May/2020:17:31:51 +0000] [info] [main] powerSaveBlockerWrapper startPowerSaveBlocker prevent-app-suspension 0
[15/May/2020:17:35:06 +0000] [info] [main] powerSaveBlockerWrapper stopPowerSaveBlocker 0
[15/May/2020:17:35:06 +0000] [error] [renderer] downloadItem Download error i [Error]: YTDL: Can't rename tmp file
at file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/bg.js:71:7823
at async file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/bg.js:71:7782
at async Promise.all (index 0)
at async file:///C%3A/Users/Dave/AppData/Local/televzr/resources/app.asar/bundle/bg.js:346:271305 {
code: 'CANT_RENAME_TMP_FILE',
original: [Error: EPERM: operation not permitted, mkdir 'S:\'] {
errno: -4048,
code: 'EPERM',
syscall: 'mkdir',
path: 'S:\\'
}
}

It appears to be some sort of permissions problem.

I am trying to save to the root of drive S: which should be OK.

The temp folder is there on the drive OK, so the program can presumably write to the drive OK, but it does not seem to be able to complete the transfer when the download is complete.

I tried resetting all the NTFS permissions on the drive, but it has made no difference.

Any ideas?

Thanks, Dave.

Try to specify some kind of a directory on the disk.

We are trying to fix the bug.

Thanks Alexander!

Yes, I have done some more tests now, and it looks as if Televzr cannot write its saved files to the root of a drive.
If you specify a folder on the drive it's fine, but not if you specify the root.

It can put its "Temp" folder in the root OK, but it appears that it cannot transfer the downloaded file from the Temp folder to the specified final location when the download is completed if it's the drive root. The downloaded file can still be retrieved from the Temp folder, but most people would not realise that of course!

This obviously isn't a big problem in itself, but it is if you don't know about it as the downloads will fail for no apparent reason! This issue should be fixed of course, but if it can't be users should be prevented from specifying the root of a drive as their save destination. Cheers, Dave.