Now that FileField is part of Drupal 7, the FileField Meta module included with FileField is without a home. Considering almost all sites will be using File module in Drupal 7, it would make sense for getID3 to provide integration with the core module and take advantage of the new FileAPI hooks. Since the FileAPI is nearly identical to the APIs provided by FileField in Drupal 6, we'd essentially need to simply rename the functions and include it in getID3. This would immediately provide getID3 module with Views integration, Token integration, and make ID3 information available immediately upon every call to file_load($fid).
Comment | File | Size | Author |
---|---|---|---|
#31 | 780848-getID3-31-fixing-views-minutes-handler.patch | 1.36 KB | ericduran |
#29 | 780848-getID3-28-fixing-views-duration-handler.patch | 1.31 KB | ericduran |
#28 | 780848-getID3-28-fixing-schema.patch | 944 bytes | ericduran |
#27 | 780848-getID3-27-update_meta_data.patch | 2.1 KB | ericduran |
#26 | 780848-getID3-26.patch | 765 bytes | ericduran |
Comments
Comment #1
davebv CreditAttribution: davebv commented+1
Comment #2
drewish CreditAttribution: drewish commentedI'm all for it.
Comment #3
RobLoachMakes sense!
Comment #4
aaron CreditAttribution: aaron commentedthis is an awesome idea!
Comment #5
klonossubscribing...
Comment #6
srgk CreditAttribution: srgk commentedwould be very cool
Comment #7
drewish CreditAttribution: drewish commentedStarted this as part of the D7CX sprint. No provisions are made for an upgrade path. I haven't gotten around to doing the ID3 tag part since I'm thinking I want to make some changes.
Comment #8
drewish CreditAttribution: drewish commentedFixed a bunch of stuff. Can't figure out how to get the views support into the patch.
Comment #9
drewish CreditAttribution: drewish commentedthis is getting towards close enough to commit. the whole id3 tag (title, artist, etc) is omitted but the view and token stuff seems to work.
Comment #10
quicksketchSweet, nice work drewish. Is there a reason for needing to comment out the tag logic from this patch? The same thing is already working AFAIK for FileField, I don't think it needs any special consideration for D7.
Comment #11
drewish CreditAttribution: drewish commentedI think we can do better in D7. I'd like to explore a sub-module that allows tags to be mapped to CCK fields and allows reading and writing of the tags. Basically I'm trying to kill off the audio module and need to figure out a way to allow users to edit id3 tags on files.
Comment #12
drewish CreditAttribution: drewish commentedI think we can do better in D7. I'd like to explore a sub-module that allows tags to be mapped to CCK fields and allows reading and writing of the tags. Basically I'm trying to kill off the audio module and need to figure out a way to allow users to edit id3 tags on files.
Comment #13
kjv1611 CreditAttribution: kjv1611 commentedIf this does end up working, is anyone going to be able to offer any sort of "tutorial" or step-by-step instructions on how to use this setup in place of the audio module? I know I'd like to be able to move my church's site to Drupal 7, and the audio module has been a key factor there - whether it or some replacement is workable - or works at least as well as the audio module.
Sounds like it's progressing well, so from a bystander point of view, it sounds good to me. :0)
Comment #14
yngens CreditAttribution: yngens commentedsubscribe
Comment #15
AdrianB CreditAttribution: AdrianB commentedSubscribing.
Comment #16
Tunox CreditAttribution: Tunox commentedwoohooooo!! great idea Nate
I can feel soon we might be able to build out of D7 and this module a lovely audio jukebox.
About time to let Jinzora fade away and retire itself.
Comment #17
mthart CreditAttribution: mthart commentedsubscribe
Comment #18
mthart CreditAttribution: mthart commented+1
Comment #19
bomarmonk CreditAttribution: bomarmonk commentedSubscribe...
Comment #20
JohnAlbinI re-rolled the patch in #9 to apply to the current master branch. And then noticed a path error in hook_help().
We need to create a new 7.x-1.x off the tip of master (
git co master; git co -b 7.x-1.x;
) and then apply this patch viagit am < 780848-20-getid-d7.patch
. Oh, and then you'll need to edit the 7.x-1.x-dev release node to make it point at the new branch.Comment #21
JohnAlbinOk, pushed a new 7.x-1.x branch from the old master branch and updated the 7.x-1.x-dev release node to use the new branch instead of master.
Then I committed the patch in #20 to a new feature branch called: 780848-merge-filefield-meta
Since I haven't tested the patch and comments #10 and #11 show the patch needs more work, I didn't want to commit the patch to 7.x-1.x.
If you want to help test this, you can follow the instructions here to checkout a copy of the work from Git: http://drupal.org/node/173580/git-instructions/780848-merge-filefield-meta
Comment #22
harriszrashid CreditAttribution: harriszrashid commented+1
Comment #23
Steven Jones CreditAttribution: Steven Jones commentedsubscribe.
Comment #24
jthomasbailey CreditAttribution: jthomasbailey commentedTried #21 and got:
I ran updates, it didn't create a new table. Am I supposed to do that by hand?
I'm confused about the id3 module... if it doesn't work with Views or Token then what good is it? Could be there's a setting I'm missing but it doesn't seem to do anything at all.
Comment #25
ericduran CreditAttribution: ericduran commentedSo on the 780848-merge-filefield-meta branch the version detection is broken.
This patch fixes it to be inline with the way the latest 7.x-1.x-dev version of the module does it.
I made it a git format-patch so git knows the branch it belong to :)
This patch is against the 780848-merge-filefield-meta branch.
Comment #26
ericduran CreditAttribution: ericduran commentedSo as mention in #24 the table isn't created if you're coming from the dev version.
This patch adds an update hook to create the getid3_meta table.
I can imaging is annoying to upload different patches in the same issue, but it seems like everything related to the 780848-merge-filefield-meta branch is being kept here.
Do we instead maybe want to create a new component so we can tag the fieldfield-meta related issues with that component or maybe even a tag and keep the issues separated?
Until I hear back I'll just keep posting them here.
This is the patch to add the update hook.
Comment #27
ericduran CreditAttribution: ericduran commentedOk and I think this is going to be the last patch needed.
This is another update hook for populating all the database from files that have already been created.
Just to reiterated. Each of my last three patches are different and solve a different issue within the 780848-merge-filefield-meta branch.
Comment #28
ericduran CreditAttribution: ericduran commentedOne more.
Note all these patches for now need to be applied in the same order I'm uploading them.
This fixing the schema to allow up 13 characters. Because getid3 something returns join stereo which doesn't fit in the previous 10 char limit.
Comment #29
ericduran CreditAttribution: ericduran commentedOk, Yet another one.
Sorry for the ridiculous amount of noise I'm making. I just keep running into each one of these issues one by one.
This patch fixes the views duration handler. Before it was assuming we'll get a proper timestamp and then formatting it with date. This is instead the value in seconds. So I'm doing the formatting by dividing the appropriate number. This patch might actually be incorrect because I'm confused as to how :minutes is supposed to be render, I'm not sure if it means total minutes, of minutes pass the hour.
Anyways here's the patch that makes at least the seconds and hours format work properly.
Comment #30
ericduran CreditAttribution: ericduran commentedAfter these patches get apply, I think the separate branch should probably be merged into the 7.x-1.x if not maybe even a 2.x branch :) (pretty please)
Comment #31
ericduran CreditAttribution: ericduran commentedLol ok this will be my last patch for the day.
This fixes the minutes, and seconds views handler to work like it used to work in D6. I did switch it to use math because I ran into issues using the date function when the TimeZone is not set to UTC.
Again just to reiterate all these patches are git format-patch patches so they need to be apply in the correct order.
Each one of them fixes a different issue.
This should be good for now. :)
Comment #32
drewish CreditAttribution: drewish commentedEric you've got commit. Play nicely.
Comment #33
klonosI think this might indeed deserve a 7.x-2.x branch.
Comment #34
ericduran CreditAttribution: ericduran commentedThanks Andrew. I went ahead an push my patches up to the 780848-merge-filefield-meta branch.
I'll like to branch of to a 7.x-2.x branch but I'll wait and see what the other maintainers think. Also I want to do more testing see if I can find any more bugs.
If I find more issues I'll probably open separate issues for them as this thread if getting a bit confusing.
Maintainers:
- Should we open another branch 7.x-1.x-dev that has this filefield-meta work?
It seems like the correct approach to me, since this is a lot of work for a point release :)
I wont take any actions until I hear back from other people.
Comment #35
rickvug CreditAttribution: rickvug commentedHappy to see this happen! The new branch is looking a great improvement.
That said I'm wondering out loud if it should be responsibility of GetID3 to store the meta data for files. What if a developer wants to store additional values from FFMPEG or the Exif data from an image? It would be helpful to have all of this data saved centrally and available via a single API that is separate from metadata extraction. I know that this is the case now that I'm starting to look into using length, width and height in JW Player module.
I found the File Metadata project (http://drupal.org/project/file_metadata) which looks very promising for this role. However there hasn't been any development for a while (#806252: Status of File Metadata module). It has a single table with columns for fid, key, value, and the module providing the data. The structure should be more flexible as columns won't need to be created for new fields that users may want to add?
Any thoughts? I don't want great to get in the way of good but now feels like a good time to work this out seeing as how there's not yet a real 2.x branch.
Comment #36
rickvug CreditAttribution: rickvug commentedLooking at the getID3 code, File Metadata would need to add a table to store information such as human name and description for Token integration and any other user facing purpose. Something like:
module: getid3
name: audio-channel-mode
human_name: Audio channel mode
description: The number of channels in the audio, by name: stereo or mono.
I've never coded views integration and I'm not sure how the formatting could be done in a generic way for each key (perhaps that would still be the responsibility of getID3?). Sorting and filtering feels like something that could be implemented systematically since the data structure would be consistent for all values.
Comment #37
ericduran CreditAttribution: ericduran commented@rickvug I see your point. The problem I see right now is that the only meta-data extraction happening right now is on getid3. If there were a couple of other modules doing the same thing it would make sense to have a separate api, but right now there isn't :-/
maybe when the file_metadata module gets some more traction we can merge them all in not really sure :-/
Comment #38
rickvug CreditAttribution: rickvug commented@ericduran Sorry for the delayed response. All I have to say is that I completely agree. :) A file meta data API makes a ton of sense but let's not let that stop this issue. If the file_metadata module matures and other projects get on board then the transition could be re-evaluated later
Comment #39
ericduran CreditAttribution: ericduran commentedI've been using the separate branch and I think is time to merge it into the -dev channel and mark this ticket closed.
Anyone has any objection?
Comment #40
oriol_e9gYeah! Go go go!
Comment #41
rickvug CreditAttribution: rickvug commentedNo objections here either. +1
Comment #42
matt_paz CreditAttribution: matt_paz commentedI'm happy to start testing this week ...
Comment #43
elBradford CreditAttribution: elBradford commentedMe too, let's get this in dev! (that's what it's for, right?)
Edit: I found (maybe) 3 issues after cloning the 780848 branch:
I rolled back to stable because this isn't vital to me. Hope this information helps.
Comment #44
drett CreditAttribution: drett commentedHas there been any more action on the dev branch? I'm desperate to have this functionality. Thanks!
Comment #45
klonos...unfortunately there haven't been any commits in dev since August 2011 :/
[edit] ...ok there's the 780848-merge-filefield-meta branch and there were a few commits back in February, but no action after that.
Comment #46
Nels CreditAttribution: Nels commentedUsing this commit, getID3 seems to be working as I expect/need it. Since I'm only using Duration (all the other data I need is in fields already), there could be problems in other aspects.
Thanks!!
Comment #47
juampynr CreditAttribution: juampynr commentedThis work is already in branch 780848-merge-filefield-meta. @ericduran, could you create a new release?
Comment #48
ericduran CreditAttribution: ericduran commentedThis branch is now merged into the 7.x-1.x branch.
This is now closed.
I know of a couple of projects using this. I'll get some feedback after they start using the dev and if everything is good.
We can probably push a 7.x-1.1
Thanks all for the reviews, commits, comments, testing, etc...
--
http://drupalcode.org/project/getid3.git/commit/3b3b8a4