[gentoo-user] Youtube-dl and file time stamps.

[gentoo-user] Youtube-dl and file time stamps.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

Howdy,

I'm not sure what causes this because it doesn't always do this.  When I
use youtube-dl to download videos, it sometimes uses the current date
and time for the time stamp.  I like that because I can sort by date and
see new videos.  On some sites tho it seems to use the time stamp of the
file on the server I am downloading from not when it was put on my
system.  Sometimes I download a video and it may have a time stamp of
years ago, decades sometimes.  I looked through the help page but can't
find a option to tell it to use local time instead of the time from the
remote server file.  Needless to say, when it does this, I can't tell
which videos I recently downloaded since sorting by time stamps is no
longer accurate. It's annoying.

Has anyone else noticed this behavior? Is there a way to tell it to stop
setting it to really old time stamps?  Some option that isn't documented
maybe.

Thanks.

Dale

:-)  :-) 

P. S. Doing pretty well with my encrypted drives and stuff.  Remembering
the passwords can be difficult at times tho. 

[-- Attachment #2: Type: text/html, Size: 1383 bytes --]

Re: [gentoo-user] Youtube-dl and file time stamps.

[Simon Thelen]

[2020-07-15 17:30] Dale <rdalek1967@gmail.com>
>Howdy,
Hi,

>I'm not sure what causes this because it doesn't always do this.  When I
>use youtube-dl to download videos, it sometimes uses the current date and
>time for the time stamp.  I like that because I can sort by date and see
>new videos.  On some sites tho it seems to use the time stamp of the file
>on the server I am downloading from not when it was put on my system. 
>Sometimes I download a video and it may have a time stamp of years ago,
>decades sometimes.  I looked through the help page but can't find a option
>to tell it to use local time instead of the time from the remote server
>file.  Needless to say, when it does this, I can't tell which videos I
>recently downloaded since sorting by time stamps is no longer accurate.
>It's annoying.
>
>Has anyone else noticed this behavior? Is there a way to tell it to stop
>setting it to really old time stamps?  Some option that isn't documented
>maybe.
You're probably looking for the --no-mtime option. Depending on what
you're using to sort your local videos you can always just tell it to
sort by ctime instead of the (probably) default mtime. Several other
file download programs set the mtime to the last-modified header or
similar, but they tend not to touch the ctime.

-- 
Simon Thelen

Re: [gentoo-user] Youtube-dl and file time stamps.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

Simon Thelen wrote:
> [2020-07-15 17:30] Dale <rdalek1967@gmail.com>
>> Howdy,
> Hi,
>
>> I'm not sure what causes this because it doesn't always do this.  When I
>> use youtube-dl to download videos, it sometimes uses the current date and
>> time for the time stamp.  I like that because I can sort by date and see
>> new videos.  On some sites tho it seems to use the time stamp of the file
>> on the server I am downloading from not when it was put on my system. 
>> Sometimes I download a video and it may have a time stamp of years ago,
>> decades sometimes.  I looked through the help page but can't find a option
>> to tell it to use local time instead of the time from the remote server
>> file.  Needless to say, when it does this, I can't tell which videos I
>> recently downloaded since sorting by time stamps is no longer accurate.
>> It's annoying.
>>
>> Has anyone else noticed this behavior? Is there a way to tell it to stop
>> setting it to really old time stamps?  Some option that isn't documented
>> maybe.
> You're probably looking for the --no-mtime option. Depending on what
> you're using to sort your local videos you can always just tell it to
> sort by ctime instead of the (probably) default mtime. Several other
> file download programs set the mtime to the last-modified header or
> similar, but they tend not to touch the ctime.
>

I found that but wasn't sure if that was what I was looking for or not. 
I'll give that a try.  I added it to the conf file.  Now to wait until
this set of videos finishes. 

Thanks much.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2220 bytes --]

Re: [gentoo-user] Youtube-dl and file time stamps.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

Dale wrote:
> Simon Thelen wrote:
>> [2020-07-15 17:30] Dale <rdalek1967@gmail.com>
>>> Howdy,
>> Hi,
>>
>>> I'm not sure what causes this because it doesn't always do this.  When I
>>> use youtube-dl to download videos, it sometimes uses the current date and
>>> time for the time stamp.  I like that because I can sort by date and see
>>> new videos.  On some sites tho it seems to use the time stamp of the file
>>> on the server I am downloading from not when it was put on my system. 
>>> Sometimes I download a video and it may have a time stamp of years ago,
>>> decades sometimes.  I looked through the help page but can't find a option
>>> to tell it to use local time instead of the time from the remote server
>>> file.  Needless to say, when it does this, I can't tell which videos I
>>> recently downloaded since sorting by time stamps is no longer accurate.
>>> It's annoying.
>>>
>>> Has anyone else noticed this behavior? Is there a way to tell it to stop
>>> setting it to really old time stamps?  Some option that isn't documented
>>> maybe.
>> You're probably looking for the --no-mtime option. Depending on what
>> you're using to sort your local videos you can always just tell it to
>> sort by ctime instead of the (probably) default mtime. Several other
>> file download programs set the mtime to the last-modified header or
>> similar, but they tend not to touch the ctime.
>>
>
> I found that but wasn't sure if that was what I was looking for or
> not.  I'll give that a try.  I added it to the conf file.  Now to wait
> until this set of videos finishes. 
>
> Thanks much.
>
> Dale
>
> :-)  :-) 

This appears to be affected by the other end in some cases.  It seems to
help in most places but not all.  To work around this, I changed the
info used to sort the files.  Sort of odd at times how it works but
anyway. 

Thanks for the info.  It's not a complete fix but it does help. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 3000 bytes --]

Re: [gentoo-user] Youtube-dl and file time stamps.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Simon Thelen wrote:
> [2020-07-15 17:30] Dale <rdalek1967@gmail.com>
>> Howdy,
> Hi,
>
>> I'm not sure what causes this because it doesn't always do this.  When I
>> use youtube-dl to download videos, it sometimes uses the current date and
>> time for the time stamp.  I like that because I can sort by date and see
>> new videos.  On some sites tho it seems to use the time stamp of the file
>> on the server I am downloading from not when it was put on my system. 
>> Sometimes I download a video and it may have a time stamp of years ago,
>> decades sometimes.  I looked through the help page but can't find a option
>> to tell it to use local time instead of the time from the remote server
>> file.  Needless to say, when it does this, I can't tell which videos I
>> recently downloaded since sorting by time stamps is no longer accurate.
>> It's annoying.
>>
>> Has anyone else noticed this behavior? Is there a way to tell it to stop
>> setting it to really old time stamps?  Some option that isn't documented
>> maybe.
> You're probably looking for the --no-mtime option. Depending on what
> you're using to sort your local videos you can always just tell it to
> sort by ctime instead of the (probably) default mtime. Several other
> file download programs set the mtime to the last-modified header or
> similar, but they tend not to touch the ctime.
>


This ended up being the best solution.  It seems to work well.  Sort of
odd in a way but as long as I can sort by the order I downloaded files,
I don't care how strange it is.  lol

Thanks.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2243 bytes --]