View Issue Details

IDProjectCategoryView StatusLast Update
0010632MMW v4Framework: Scripts/Extensionspublic2013-07-20 08:11
ReporterLudek Assigned To 
PriorityhighSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version4.1 
Target Version4.1Fixed in Version4.1 
Summary0010632: SDBPlaylist::LastModified
DescriptionWe should add SDBPlaylist::LastModified to the scripting interface as we already use it internally in MM 4.1 because of WiFi sync.
Additional Informationhttp://www.mediamonkey.com/wiki/index.php/SDBPlaylist
http://www.mediamonkey.com/wiki/index.php/ISDBPlaylist::LastModified
TagsNo tags attached.
Fixed in build1650

Relationships

related to 0006712 closedLudek ISDBApplicationEvents::OnPlaylistModified event needed 

Activities

Ludek

2013-03-12 11:41

developer   ~0035344

Fixed in build 1628 and documented.

peke

2013-03-15 03:52

developer   ~0035387

Last edited: 2013-03-15 03:54

Can you modify this to to return Integer/LongInt and use Localized formatting?

1. Property Get SDBPlaylist.LastModified (DateTimeFormat as String) LastModified as String. NOTE: Providing Empty Parameter should use same formatting used in Showing Dates in Track View.

2. Property Get SDBPlaylist.LastModifiedInt LastModified as Integer

zvezdan

2013-07-10 14:30

updater   ~0036790

@ Peke: Why would you want that? There is already date/time variable type which is independent of the current Locale settings. If you want string representation of the date using Localized format, then just use FormatDateTime VBScript function. Also, I don't know how you could represent some date/time variable as and integer when they are internally stored as a double real value.

zvezdan

2013-07-10 14:42

updater   ~0036791

Thanks for adding this property, but is there any chance that we get an event which would inform scripts when some playlist is modified [6712]?

I have a script (Export/Create Playlists for Child Nodes) which periodically exports all child playlists of some specified one as .m3u files. I think it would be better if my script is informed by program when some playlist is actually modified which requires for it to be exported as .m3u file than to do that with some timer every xx seconds and to export even playlists that are not modified in the meantime.

peke

2013-07-10 20:43

developer   ~0036794

@Zvezdan
Main reason is to be independent of system and handle it internally eg. excluding VBScript in this case
1. Some users Would like to have ability to set own Date/time format or just Date directly formatted for HTML, ... independently of Localized format.

2. Haveing internal Unix UTC integer result is useful for cross platform usage as it is much easier to manipulate than double real

zvezdan

2013-07-10 22:47

updater   ~0036804

1. I am sorry, but we obviously don't understand each other. The date/time variable type is system independent. String representation of some date is system dependent, so having that property with string argument is opposite to your needs.

2. Having date/time variable with UTC or some another time zone is independent of its formatted string representation. We could discuss if that date/time variable should return UTC value or value for some local time zone, but that variable still should be date/time, not a string, and especially not an integer.

peke

2013-07-11 02:05

developer   ~0036805

Last edited: 2013-07-11 02:10

1. Most likely, we can talk about that on phone or IM if needed. Ludek pointed that http://www.mediamonkey.com/wiki/index.php/ISDBPlaylist::LastModified return string in "YYYY-MM-DD HH:MM:SS" I was thinking that there is an optional parameter to make resulting string in different format/localization. Some apps can require different format as input to correctly handle date/time

2. For example Last.fm uses Unix Time for scrobbling, intention was to get speed due the fact that math calculations are faster than string manipulations. eg. track differences, setting timers, ...

Other than that you are completely right.

zvezdan

2013-07-11 12:33

updater   ~0036809

1. I am sorry, I saw it just now that it returns a string, which is really weird if you ask me. Every other date/time property returned by your API is giving a true date/time type variable as VarType = vbDate = 7, e.g. ISDBSongData::DateAdded, ISDBSongData::FileModified, ... So, using a string for just this property is at least inconsistent with the rest of API. The description of it is also inconsistent: first we have mentioned Date type (Property Get LastModified As Date) then we have the mentioned string thing that you quoted. Have you tried that property?

As I said there is no need for any additional parameter. You just need to modify that property to return vbDate variable type, and using some function like FormatDateTime you would get the localized string representation of that value.

2. I am not the one who wanted string value as a result, it was you. If you look again what I wrote, you would see that I am talking about date/time variable type all the time. Also, you would see how I mentioned that date/time is actually stored as a double real value (the integer part representing date and the decimal part representing time). I suppose that you know that real variables are doing "math calculations", not string.

zvezdan

2013-07-11 17:24

updater   ~0036813

I just checked, the mentioned property has VarType = vbString = 8. I cannot see any valid reason why it is like that. Please developers, would you make that consistent with the other date/time properties and modify it to be vbDate type?

Ludek

2013-07-11 19:41

developer   ~0036816

Last edited: 2013-07-11 19:46

Fixed the format in build 1648.


The event would be a little bit tricky as the update is currently done using DB triggers, but feel free to enter it as separated issue.

zvezdan

2013-07-12 06:04

updater   ~0036828

#Ludek: It is already entered as an issue [6712]. I don't know how your code works internally, but I suppose that DB trigger cannot change some API property by itself, right? So I suppose it is your Delphi code that changes the LastModified property based on some conditions, and in the same place of the code where you change that property you could raise the suggested event.

By the way, I looked at the updated description of this property and I see that you still have mentioned UTC. Again, I cannot see any valid reason for that and I think that this property should return value for the local time zone to be consistent with other date/time properties like DateAdded and FileModified.

Ludek

2013-07-12 08:38

developer   ~0036829

Last edited: 2013-07-12 08:39

Changed from UTC to Local time (per Zvezdan request) in build 1648.


Re: the event:
No, delphi code currently doesn't change the LastModified property, DB triggers change it and delphi just reads LastModified from DB. Let's keep it tracked as 0006712

zvezdan

2013-07-17 14:09

updater   ~0036887

Is it possible that this property (and the corresponding DB field) be updated for the autoplaylists as well, e.g. when using the Edit Autoplaylist option from the pop-up menu? I guess that you could add one new trigger to Playlists table which would fire when the QueryData field change. Of course, in that case only the playlist definition is changing, but its content could be changed too.

If it is not possible, you should mention in the Wiki documentation that this property is valid only for static playlists.

For what are you using the new LastContentHash field and when and how is it changed?

Ludek

2013-07-17 15:23

developer   ~0036891

Last edited: 2013-07-17 16:08

Zvezdan, you have a good guess that LastContentHash field has been added because of this purpose. It is used prior to WiFi/USB sync to find whether auto-playlist content has changed from the last auto-sync and update its LastModified if it has been changed.

The only problem is that this check is currently performed only before device sync (when preparing tracks for sync). So if anyone doesn't sync with a device on a regular basic, then the LastModified is not updated for auto-playlists.

The solution would be to run a background task that would do this, but this task can consume quite a lot of resources and question is how often it should be called.

zvezdan

2013-07-17 17:18

updater   ~0036894

I agree that periodical check of the auto-playlist's content in the background could be time consuming and maybe it wont be necessary.

However, I think that you should at least update the LastModified property for auto-playlists when user change their definition and to generate the new OnPlaylistChanged event in that case.

Ludek

2013-07-18 13:06

developer   ~0036903

Last edited: 2013-07-18 13:07

Auto-playlist's content can be self-changed anytime (not only when user changes criteria), e.g. 'Last 50 Played', 'Recently Added' etc.

Therefore I've added this check/update for auto-playlists whenever the auto-playlist's content is loaded (e.g. in tracks view). This is not time/resource consuming, because the auto-playlist's content is already loaded in memory.

Added in build 1650.

Ludek

2013-07-18 13:15

developer   ~0036904

Added also the OnPlaylistChanged event for auto-playlists in build 1650.

zvezdan

2013-07-18 13:45

updater   ~0036906

Yes, I know that content can be self-changed, but I didn't want to suggest the solution which you have implemented because I though that it would interfere with the mentioned WiFi/USB sync modification of those new fields.

I suppose that the content is loaded into the tracklist even when user change the definition of the auto-playlists, since there is no other way for users to modify its definition but using Edit AutoPlaylist option with the previously selected auto-playlist node, right?

Do you compare the content of the current auto-playlist with the last content, or you change LastModified property whenever the content is loaded in the tracklist even if that content is not really modified from the last loading?

Ludek

2013-07-18 17:20

developer   ~0036907

Sure, I update it only when the LastContentHash differs.

zvezdan

2013-07-20 08:11

updater   ~0036937

Verified in 1650. Many thanks!