INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Cover art size  (Read 20584 times)

gtandzi

  • Recent member
  • *
  • Posts: 42
Cover art size
« on: June 22, 2015, 10:52:52 pm »

Is there a way to set up a smartlist that shows cover art smaller than 500 x 500 (say) so I can put larger higher resolution pictures in? (or some other way of achieving the same thing?)

I tried using Image Height and Width, with very inconsistent results.

Graham T
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #1 on: June 23, 2015, 01:39:53 am »

Well, Image Height and Image Width are what you have to work with, but it seems the data is not fully populated - probably because the fields are relatively new?

I found that doing a Tools->Cover Art ->Quick Find in Directory

Was a good way to populate the fields, after which a smartlist looking at Image Height and Image Width has much more to work with...
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #2 on: June 23, 2015, 04:49:56 am »

Actually, I take that back... it seems the image size data might be calculated when you look at the file... which makes using smartlists with those fields impossible...

Hmm.
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42447
  • Shoes gone again!
Re: Cover art size
« Reply #3 on: June 23, 2015, 07:41:13 am »

Actually, I take that back... it seems the image size data might be calculated when you look at the file... which makes using smartlists with those fields impossible...

Hmm.

The 'Image Width' and 'Image Height' fields are regular database fields and the value is stored.
Logged
Matt Ashland, JRiver Media Center

ldoodle

  • Galactic Citizen
  • ****
  • Posts: 411
Re: Cover art size
« Reply #4 on: June 23, 2015, 07:50:35 am »

The 'Image Width' and 'Image Height' fields are regular database fields and the value is stored.

Hi Matt,

What's the 'native' resolution of artwork in Theater View?  Obviously if the available cover art is 1400x1200, Theater View scales it down, and if it's 280x240 Theater View scales it up.

So what does Theater View scale to?
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42447
  • Shoes gone again!
Re: Cover art size
« Reply #5 on: June 23, 2015, 08:03:19 am »

So what does Theater View scale to?

The size that it's rendering the artwork at.  It picks a size and the artwork just tags along.
Logged
Matt Ashland, JRiver Media Center

ldoodle

  • Galactic Citizen
  • ****
  • Posts: 411
Re: Cover art size
« Reply #6 on: June 23, 2015, 08:24:47 am »

The size that it's rendering the artwork at.

Yeah - is it not fixed at a certain resolution?

This is the view I'm referring to.

Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #7 on: June 23, 2015, 08:35:01 am »

The 'Image Width' and 'Image Height' fields are regular database fields and the value is stored.

Something may be broken then...  I created a smartlist working with Image Height and get inconsistent results.  And when I scroll down a files view I see data populating as I scroll...?

Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42447
  • Shoes gone again!
Re: Cover art size
« Reply #8 on: June 23, 2015, 08:39:23 am »

I see data populating as I scroll...?

Well the field might not fill until the thumbnail is built.
Logged
Matt Ashland, JRiver Media Center

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #9 on: June 23, 2015, 08:45:21 am »

That's interesting about the "populating as you go" and thumbnail building.  I'm not sure how what the status of my thumbnails were when I first tried a list like this, but my list seemed to miss a lot of artwork that should have been caught by my list.  That was when I first got MC and I was very new to making smartlists.

I tried again a few weeks later, and a very similar list definition picked up everything I thought was missing... I wonder if thumbnails were built in the meantime?  An easy way to check is Help > System Info and looking under Processing for thumbnail status.

My current smartlist definition is very simple.  It finds any art that's less than 491 in height or width:

([Image Height]=<491 [Image Width]=<491)

Works here with 100% of thumbnails built.

Brian.
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #10 on: June 23, 2015, 09:40:43 am »

Well the field might not fill until the thumbnail is built.

Argh.  Somehow all my thumbnails are gone.  Rebuilding now and will then retest the smartlists.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5242
  • "Linux Merit Badge" Recipient
Re: Cover art size
« Reply #11 on: June 23, 2015, 10:33:42 am »

Argh.  Somehow all my thumbnails are gone.  Rebuilding now and will then retest the smartlists.


Any time you do a library restore from a backup all your thumbnails get blown away and need to be rebuilt.  It took me a couple go-rounds before I caught that.
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #12 on: June 23, 2015, 11:05:04 am »

Must be something else I've done recently.  Anyway, rebuilt and now I can use the Image Height and Width to do what is asked of above.
Logged

gtandzi

  • Recent member
  • *
  • Posts: 42
Re: Cover art size
« Reply #13 on: June 25, 2015, 01:03:39 am »

Mmm. Not working for me.

I set up a smart list with the only criteria [Image width] < 10, and it picks up all sorts of things, including files with an image size of 1500px x 1500px, and also picks up some tracks from albums but not others, even though I can check and see that all tracks have the same file for cover art.

Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #14 on: June 25, 2015, 01:19:46 am »

Tools->Options->Tree&View->Thumbnails->Build Missing Thumbnails

And then try again?

Logged

gtandzi

  • Recent member
  • *
  • Posts: 42
Re: Cover art size
« Reply #15 on: June 25, 2015, 09:04:21 pm »

Sadly, nope.

However, I think I've discovered the problem - the cover art that shows up in ID tag isn't the same one that JRiver uses. From force of habit as much as anything, I use Jaikoz to clean up and update the tags on my music, and it regularly finds good quality hi-rez cover art. However, this cover art doesn't get picked up by JRiver. So, for example, on the album 'Remembering John Martyn', Jaikoz finds and supplies a 800px x 800px .png file for cover art, whereas if I check cover art in JRiver using 'get from internet' it offers me 240 x 240 Your library (also on server) which (as I understand it) means that

1.
Logged

gtandzi

  • Recent member
  • *
  • Posts: 42
Re: Cover art size
« Reply #16 on: June 25, 2015, 09:07:27 pm »

(continuing - that was weird - just closed and posted suddenly mid writing)

1. Although every other kind of idtag edit program I have shows thse files as having a 800 x 800 image for cover art, JRiver is not using this version, and

2. If I try to update from within JRiver, it limits me to 225 x 225, unless I update manually.

Is this true, and if so, isn't it an unfortunate limitation?

Graham T
Logged

ferday

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1732
Re: Cover art size
« Reply #17 on: June 25, 2015, 10:40:04 pm »

MC routinely supplies me with 1000x1000 or more, there is no limitation

just try "quick find in folder...", if you have a folder.jpg there at 800x800 it will find it fine
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #18 on: June 26, 2015, 12:42:36 am »

Does MC even support PNG for covert art?  This could be the source of the problem.  Try converting the art to jpg.  Or open the PNG in a viewer, copy the image to clipboard, and then highlight the album files in MC and library tools->cover art->paste which will convert the format for you into on MC can use. 
Logged

gtandzi

  • Recent member
  • *
  • Posts: 42
Re: Cover art size
« Reply #19 on: June 28, 2015, 03:18:48 am »

OK. More playing. It's not that png is the issue, as I have other situations with hi-rez (ie >1000px x 1000px jpgs) cover art, that still don't show in JRiver.

Clearly JRiver puts its cover art somewhere different within the metadata than most other metadata editors.  It also appears that the resolution that JRiver offers depends very much on what's already been put there - and if the 225 x 225 image is what I have, and it's the best that anybody else has, then that's what JRiver offers when you apply Cover Art/Get from internet - even if I've already put a much larger image there via Jaikoz (or any other metadata editor).

So far the only way I can see to fix this problem is to find the image on the web somewhere, cut and paste within JRiver via 'cover art/paste from clipboard'; then to do the right thing by everybody else, 'cover art/submit to internet'; and finally 'cover art/get from internet' to see that it got there successfully. And while you can do this album by album (rather than track by track), it's still pretty slow and pernickety.

Isn't there a better solution?
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #20 on: June 28, 2015, 03:44:07 am »

Options->File Location->Cover Art tells MC where to store cover art in your install

Tags:

Image File: where the image is
Image Width:  width of image
Image Height: height of image

JRiver's image database is user created, so will only have what others have submitted, and from there you can choose the best available.  Or, as you are now doing, source your own cover art. 

Options->General->Online Metadata->Submit Cover Art - if checked will automatically upload any new art you add - no need to manually submit.

What most will do, I guess, when the Get From (JRiver) option doesn't turn up anything useful is go grab from elsewhere, eg Google/Amazon etc and then paste into their collection.  Many will use the link bar and create a search link that they can just click on to launch a search.

Options->General->Features->Link Bars

Great explanation of links here: http://yabb.jriver.com/interact/index.php?topic=83371.0

Logged

gtandzi

  • Recent member
  • *
  • Posts: 42
Re: Cover art size
« Reply #21 on: July 02, 2015, 01:55:59 am »

Sorry to carry on with what I assume is fairly trivial for most people - after all sound quality is number one priority for most of us I guess, but having got that to my liking, I would like to display non-pixellated cover art.

Anyway - yes I can and do all that you suggested - pain in the album by album neck it is too.

BUT, my smartlist is still a very unreliable collector of low-quality art. I use "[Media Type]=[Audio] [Image Width]=<300 ~sort=[Filename],[Media Type],[Album Artist (auto)],[Album],[Disc #],[Track #],[Name]", and it picks up

1. Many albums with art >300 - in fact as big as 1500.

2. Single tracks from albums which I know have all the same art, and just in case check that by going into album view, finding the album, right clicking on the album cover and clicking 'Cover Art/Get from Internet..' that the cover art for the album is > 300.
Logged

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1855
Re: Cover art size
« Reply #22 on: July 02, 2015, 02:13:24 am »

Sorry to carry on with what I assume is fairly trivial for most people - after all sound quality is number one priority for most of us I guess, but having got that to my liking, I would like to display non-pixellated cover art.

Anyway - yes I can and do all that you suggested - pain in the album by album neck it is too.

I see it differently.  For me it's an opportunity for quality control: I scan all my own artwork and apply colour correction and other processing to ensure I get the best possible artwork...   For download music it's more tricky and there I am using a combination of MC's database and other sites (google etc) to try and source the best quality image I can find.

Again, the MC cover art database is user created.  If nobody before you has done the "work" you'll have to find the artwork somewhere else.  However, assuming it's there, on to the next problem...

Quote
BUT, my smartlist is still a very unreliable collector of low-quality art. I use "[Media Type]=[Audio] [Image Width]=<300 ~sort=[Filename],[Media Type],[Album Artist (auto)],[Album],[Disc #],[Track #],[Name]", and it picks up

1. Many albums with art >300 - in fact as big as 1500.

Using your rules I only see artwork <= 300 width... 

Have you confirmed all your thumbnails are built?  In the right hand tree go down to Services & Plug-ins->Reporter - you will see a report of various data including the % of thumbnails built.

If not 100% - Options->Tree & View->Thumbnails->Build Missing Thumbnails

Quote
2. Single tracks from albums which I know have all the same art, and just in case check that by going into album view, finding the album, right clicking on the album cover and clicking 'Cover Art/Get from Internet..' that the cover art for the album is > 300.

If you need to "clean up" individual tracks, albums, it's probably best to use:

Right click on the offending album/tracks->Cover Art->Remove Cover Art

This should ensure that the cover art fields are clean.  And THEN do your get from internet/paste/whatever.



Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #23 on: July 02, 2015, 07:22:04 pm »

I'm very confused by this thread.

1.  I've added album art from external taggers and JRiver sees it.  I no longer use another program though, as JRiver makes it very easy.  Does your external art tagger do something special?
2.  I have a smartlist that searches by Image Height and Image Width.  It wasn't working at one point, but now it does.  Perhaps that's the whole mystery here.
3.  Why all the discussion about how JRiver shows possible artwork when you select "get from internet"?  That's not part of the problem at all is it?

Brian.
Logged

gtandzi

  • Recent member
  • *
  • Posts: 42
Re: Cover art size
« Reply #24 on: July 02, 2015, 09:29:50 pm »

Yes. Thumbnails built. And checked that they are all built.

Confusion about individual tracks. Issue as I see it. (i) individual track appears in lo-rez art smartlist; (ii) the art is not lo-rez; (iii) the art is exactly the same as on every other track on album; (iv) nevertheless, replacing the art on the whole album doesn't fix the problem.

External taggers. I've been a long term user of Jaikoz, principally because I used it before JRiver came out, and it aggregates all the major databases, often giving me additional information such as composer/s, and almost always finds the best available album art (or at least as good as I can find easily using Google images). However, the art it adds often doesn't get picked up by JRiver - no idea where it goes. I can open the same tracks in JRiver and Jaikoz and each shows me different art.

Do you have any idea what you (or it) changed so your non-working smartlist started working? Perhaps its the same problem mine has.

Wasn't aware that there was 'all the discussion about how JRiver shows possible artwork..' except insofar as it relates to the point about external taggers above.

Not being sarcastic, just frustrated. And given I have over 50,000 tracks, and around 17,000 of them appear in my lo-rez art smartlist - of which perhaps 20% are genuinely lo-rez, which then makes me doubt whether it's picking up all real lo-rez art -- I'd really like to find a way to automate this process.

So, thanks to all.
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #25 on: July 02, 2015, 09:42:35 pm »

Does Jaikoz embed the art inside the file?  If so, I don't know how JRiver would not see it *unless* you have JRiver set to NOT update the database from file tag changes.  Under configure audio import there's a checkbox option for "update for external changes".  I believe that reads tags and embedded art from the files whenever they change.  It's how mine is set and seems to work.

I'm not sure what made my smartlist work.  I only know had it build a few missing thumbnails in between it not working and later working.  But my tests were VERY far apart, so I'm not sure.

My comment about the discussion about how JRiver presents choices of artwork through "get from internet" was because I don't understand how it's related.  I just re-read part of your comments and now I'm really not sure.  To be super sure what art JRiver sees, I would play a few files and see the art displayed.  Set scale to 100% and you'll definitely see what JRiver sees.

I keep coming back to thinking that one of the two programs here is not embedding art work.  What kind of files do you primarily have?  (MP3, AAC, FLAC, etc)

Brian.
Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Cover art size
« Reply #26 on: July 03, 2015, 04:15:25 am »

Brian's ideas and questions are good.

I think Jaikoz does write Cover Art into tags, or at least has the option to. Much like Musicbrainz Picard. But the format of the music file makes a difference. MP3 and FLAC file tagging is very standardised, but WMA file tagging is not. Hence Brian's question.

Note that "Image File" tag says "Inside File" if an image in a tag in the file is being used. If an external image file is being used when running MC directly on a local machine, which may be a server, then the "Image File" tag shows the file name of the image. When running MC on a client, then the "Image File" tag shows the path and file name of the image. That may make it easier to work out the source of the Cover Art.
Other settings that may be relevant;

Options/Library & Folders/Configure Auto-import/Write file tags when analysing audio, getting cover art, and applying folder-based tags.

So tags will be written when getting Cover Art during Auto-import.

Options/File Location/Cover Art/Also store image in file's tag.

I assume that MC will find Cover Art in tags regardless of these settings, but maybe there is some priority for external Cover Art files over internal tags, if this is not set.

Okay. Must go. But also note, if you are updating Cover Art from a MC Client rather than the Server, strange things can happen. Like image files being stored locally under the Windows User directory, instead of on the server. I'm not sure that the Cover Art will even get saved into a tag in the file on the server when working from a Client. But I ran out of time to test.

Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

paultaylor

  • Member
  • *
  • Posts: 2
Re: Cover art size
« Reply #27 on: November 04, 2015, 10:37:35 am »

I think Jaikoz does write Cover Art into tags, or at least has the option to. Much like Musicbrainz Picard. But the format of the music file makes a difference. MP3 and FLAC file tagging is very standardised, but WMA file tagging is not. Hence Brian's question.

Hi, Jaikoz developer here yes Jaikoz does always embed artwork into the metadata, for WMA this would use the "WM/Picture" tag - which I believe to be the standard for WMA files. Jaikoz does not write the artwork as a separate folder.jpg or folder.png file at save time because its much harder to keep separate image files with the correct songs once songs start getting moved around.

However you can make Jaikoz write out the images on an image per folder basis using File:Save Artwork to FileSystem, and in Preferences:Local Correct:Artwork Correct you can specify the name to use, (its defaults to folder)

hope that helps.
Logged
Developer of Jaikoz and SongKong Music Taggers

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Cover art size
« Reply #28 on: November 04, 2015, 05:04:48 pm »

G'Day Paul and welcome to the forums.

Thanks for the confirmation. I had a quick look around your help files online and couldn't find any information about which other fields are supported in WMA files, using Jaikoz. Nor did a quick internet search. As one of the MusicBrainz developers, you would be aware of the simple tag mappings page on their site, which unfortunately doesn't include WMA file types. I couldn't find a similar simplified mapping on your site.

Do you have such a simple tag mapping between files formats? Such a mapping would make it much easier for us laymen to understand which formats support which tag types, and their names. I do have several hundred WMA files, which I could convert to enable tagging in the files, but I would like to know how much tagging could be done in the existing WMA files.

Of course, the answer may still be of limited use, if the player I am using can't read the tags. It appears that neither JRiver MC or MusicBrainz Picard write tags to WMA files, but I'm not sure if JRiver MC can read them from the files. Plus of course many portable players aren't going to read the WMA tags. Still, I would prefer to preserve the original file format I have, WMA, and put tags into the files for archival purposes. So I would like to understand what Jaikoz can do in this regard.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #29 on: November 04, 2015, 05:21:48 pm »

Since this thread, I've developed a View that I call "Cover Art Review".  I've set up Panes in this view that allow me to:

1.  See all files.  See files missing cover art.  See files with cover art below my threshold (which is 480 x 480).
2.  Optionally mark some cover art as "good enough" even if it's smaller than my threshold value.  Once marked, I can choose to not see those files in my view by clicking a selection.  Or I can include them by clicking a different button in the same Pane.
3.  Show ranges of image Heights or Widths.  This is useful in determining if (for example) I have tall skinny cover art for some files (which I do), or if I just have generally small art.  I can filter by Height and Width individually.
4.  Of course, limit by Artist, Album, or both.

What am I even thinking?  I should just post a screen shot.  A picture is worth 1000 words.  (Pun sort of intended!)  :)

This makes finding small cover art, or songs without cover art very convenient.  Cover art maintenance becomes much more straight forward and simple with a view like this one.

Brian.

Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Cover art size
« Reply #30 on: November 04, 2015, 06:41:25 pm »

What a shame you can't just export that view and attach it for us to import.

Or can you? I don't think that works for such a view, especially with at least one custom field (Approved Cover Art checkbox). I read that thread discussing the View save and load functionality a while back.

I really need to start building some useful views such as yours and a bunch of other people's. I like your addition of a Tools group as well.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #31 on: November 04, 2015, 06:57:02 pm »

I'm not totally sure if this view will import or not, but I'm attaching it for you to try if you'd like.  In case you feel like really getting detailed with this, my custom field is named "Image Approved".  I wouldn't think this would keep the view from working, but I'm not sure so...

Anyway, View attached.

Brian.
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #32 on: November 06, 2015, 05:11:20 pm »

Any luck with loading the View Roderick?

Brian.
Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Cover art size
« Reply #33 on: November 06, 2015, 08:26:07 pm »

Yes, I was able to load it but I either did it the hard way, or a sort of work around is required.

I tried to set up a Tools menu item like you have, but I could only work out to add a view at the root level of the menu system, rather than just a menu that contained views, like the standard Audio, Images, Video, etc. menus. So I am about to research how to create an empty menu item to place the view in, or move it to.

Also, I had to create a view, and then within that view, load your view to overwrite what I had created. Again, I couldn't work out how to just load your view as a new view, so I will be researching. I also still need to add your "Image Approved" field. The view worked fine without it, just leaving an unlabelled column the width of a checkbox.

So, still some work to do working out how to do this easier, and consistently. But that is probably mostly because I haven't played around with Views much as yet, so I'm a novice with them.

Actually, I just added the "Image Approved" field with Data Type "String" and edit type "Check", and the view seems to be working a little strangely with the field checked. I expected ticking all the image/files for an Album and then selecting the "Removed Approved" filter would result in that one album being hidden, and everything else still being shown . . . Ah, I see. I created the field with no initial value, just blank. The field needs to be either 0 or 1 for the view to work. I need to set the value for all records to 0 initially. There doesn't seem to be a way to do that when creating a field either. I am hoping new records are created with a default of 0, which is unchecked. I shall see later.

Just selected all files, ticked the "Image Approved" field, then unticked. All working as expected now.

Anyway, I am currently playing with this on my Client PC, which isn't a good idea, so I'll move to my HTPC MC Server soon and play some more. Learning to do as well.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Cover art size
« Reply #34 on: November 07, 2015, 08:18:25 am »

Yes, I was able to load it but I either did it the hard way, or a sort of work around is required.

Everything you said after this sounds correct.  Loading views requires "the hard way" unfortunately.  :)  BTW, you could have put my view anywhere; it doesn't need any special container.  As long as the parent view can see the files, it would be fine to put it in Audio, or where ever you can see audio files.

Like I said, it sounds like you did everything correctly.  Good job! 

Brian.
Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Cover art size
« Reply #35 on: November 07, 2015, 04:51:42 pm »

Thanks Brian.

After reading up lots about Views yesterday, I think you are right!

I deliberately copied your idea of the "Tools" group to put stuff that wouldn't be used too much into. I didn't want utility type views mixed in with entertainment type views. Also, as my top level view, the Tools group, now has no filter on it, and shows all files, I can put all sorts of views in there for different media.

I found discussions about saving and loading views, and how sharing them is difficult. It would seem that a complex view with expression fields and such would require quite a write-up for another person to follow, in addition to the jvi file.

Anyway, now that I have started, I will continue to play with views and see how much trouble I can get into.  :D
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Cover art size
« Reply #36 on: November 16, 2015, 11:18:51 pm »

Actually, I just added the "Image Approved" field with Data Type "String" and edit type "Check"

Doh!

I have just found out that I should have made that an Integer field, and if I had I wouldn't have had a problem initialising the field.

Ah well, it can be changed, so no problem. Glynor set me right: https://yabb.jriver.com/interact/index.php?topic=101404.msg703383#msg703383
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

Absinthe

  • Guest
Re: Cover art size
« Reply #37 on: October 22, 2019, 01:28:10 pm »

Yes, I was able to load it but I either did it the hard way, or a sort of work around is required.

I tried to set up a Tools menu item like you have, but I could only work out to add a view at the root level of the menu system, rather than just a menu that contained views, like the standard Audio, Images, Video, etc. menus. So I am about to research how to create an empty menu item to place the view in, or move it to.

Also, I had to create a view, and then within that view, load your view to overwrite what I had created. Again, I couldn't work out how to just load your view as a new view, so I will be researching. I also still need to add your "Image Approved" field. The view worked fine without it, just leaving an unlabelled column the width of a checkbox.

You've got me working on this idea as well.  I currently have a ton of smart lists as tools to weed out missing cover art, incorrect track names (compared to the file name) and a ton of other checks.  The problem with them in my smart lists is it takes some time to load the parent view.  Very annoying in Theater Mode.  So now instead of smart lists, Im moving them to actual views and into a Tools view off the root.  Ironically, I just created the root view "Tools" and then moved Brian's file into the saved Views folder under "C:\Program Files\J River\Media Center 25\Data\Saved Views" and then created the new view in MC based on the saved view.  It came out with all the settings and searches and such.
Logged
Pages: [1]   Go Up