Hi

what button are you pushing to have the changer read / cataloged all your disc?


Len

Quoting dkgibson:

Quote:
If you don't know what that is, it's a 400 DVD/CD disc changer/player (HDMI 1080i).

Pros:

1. You load up all your discs, push a button, and come back in an hour, and it has read / cataloged all your discs and placed them in an on-screen menu, from which you can play them.  You can also add/remove discs to the menu.

2. When it can't read the catalog info from the disc, you can manually enter it via a PC keyboard (not included).

3. Sony even provides a free firmware upgrade.

Cons:

1. For some reason, it can only determine the title of about 30% of my DVDs;  the rest I had to enter manually.  This means that if you move such a DVD from one slot to another, you have to enter the info again.

I sold the Sony DVP-CX995V on eBay (for $275) and bought the Blu-Ray version ($719).  Besides being able to read Blu-Ray (as well as DVD/CD) discs:

1. Unlike the DVP-CX995V (which reads the DVD title information from the DVD), the BDP-CX960 has a (wired) Ethernet port, and downloads title/director/genre/etc information from the Internet (Gracenote).  It also does a decent job on music CDs.

2. Unlike the DVP-CX995V (which only was able to obtain title information from about 30% of the DVD discs), the BDP-CX960 (via Gracenote) recognizes virtually all of my CD/DVD/Blu-Ray discs.

3. Firmware updates are also done via the Internet, with automatic notification of availability.

4. Unlike the DVP-CX995V (which on power-up would always spend about 30 seconds loading the "current" DVD before it would even recognize remote control commands to go to "folder view" mode), the BDP-CX960 starts up faster and goes straight to the BDP-CX960's home (folder) menu.

5. The BDP-CX960's menu system is vastly improved and expanded.

Cons:

1. There is no provision for updating disc information via keyboard.  You can do it via the remote control without too much difficulty, but since there is an Ethernet port, where is the embedded web browser for EASILY making such changes???

All in all, I'm very satisfied with the changes.

Quoting mediadogg:

Quote:

b. I find it strange that you are inserting DVDs in the middle of your changer.

DVDs start at 2, except those that are going to be replaced very soon w/ BDs, which start at 90.
BDs start at 100.
Music CDs start at 400 and work backward.

This allows my bookcase to have the empty boxes in the same order as the discs, and still look orderly.

Quote:
One big surprise to me is that there is NO WAY to give the CX960 a command to go to a specific slot. So, LoadDVD is useless for selecting a DVD from the DVP-CX960.

Note that you can go to slot #1 via "rental load", which will give you an absolute position (if the s/w knows the # of the first slot with a disc present) but that's using an atom bomb to kill a flea (and slow as well).

Quote:
But I cannot understand why they would cripple the unit by not allowing the selection of a Slot#. Bummer. I am hoping that a firmware upgrade will someday allow IP control via the Ethernet port.

I experimented with keying the slot number on the remote at various points in the player's menus, but got nowhere.  Note that the "channel up/down" remote buttons move through the discs in numerical order, but once you stop moving, the disc is selected and played.

Re crippling:  Lack of imagination in design, especially present in large companies.  I once did some consulting for a HUGE computer company, and since the company would give any employee any software in the company, VERY FEW employees were aware of s/w outside the company, which meant they weren't exposed to different ways of looking at things.  I'm retired from 40 years of s/w development, and it astounds me the number of times I see an absolute lack of imagination in product design (often the company gets embarrassed in a product comparison review).  The bigger the company, the more imagination is suppressed.  Often they come around eventually, but it can take ten years.  I know of of one major camera manufacturer that took a decade to allow users to perform firmware updates on $3000 professional cameras (it took a bit less for the consumer division to see the light, but then they had more competition).

Given all the GPL & open source code in the product, one hope you might have is to get a copy of the source (and perhaps a config file or two) and find out how to open up a port (eg, telnet, ssh).  Apparently PuTTY is on the box, but that might be there for scripted client usage.  An "nmap" scan of all ports from 1 to 65535 shows none open.

What I would like to see in "DVD Profiler" is SQL support for a database (local or remote) via ODBC.  Then the data (at least the collection part) would be in a standardized database where I could create web pages (using PHP) to select and display data to my heart's content.  I do that now for the entire FCC database of amateur radio callsigns (www.ae7q.com) and FAA airmen and airports (www.airmen.aero), and the amount of effort to add new ways of displaying data is AT LEAST one order of magnitude easier than hard-coding the same thing into a s/w app.  In fact, I was going to build a DVD SQL database like that last weekend, but then I found DVD Profiler.  My database would have been VERY BASIC, without all the DVD details;  just enough to create a usable listing of discs (no lookups to external data).  DVD Profiler provides a LOT MORE data with MUCH LESS data entry.  However, it's limited like every program of this type is:  Every bit of flexibility needs to be coded into the program (and TESTED), and that's a lot of work.

Of course I can export my own collection from DVD Profiler and still create my own SQL database, but without the huge amount of movie data that Invelos has, it seems pointless to me, and exporting data from DVD Profiler every time a collection changes, isn't my idea of fun.

I don't know the internals (or even the design history) of DVD Profiler, but it's not consistent wither several tenets of good DB design, the first of which is to not duplicate identical data.  Ideally (and this is off the cuff;  there may be additional issues):

1. There should be one DB table for "productions" (same director/cast/story), which would reference other tables as necessary (eg, cast/crew info, genre).  Right now, for various releases of the same movie, there is duplicate and/or inconsistent data.

2. There should be one DB table for "releases", which would contain details about each release (or feature).

3. There should be one or more DB tables for each "media" (eg, multiple movies/features on a single disc, box sets, etc).  This keeps the DB tables for #1-2 above, conceptually "clean" (and hopefully invariant).

The above data is user-independent.  Then for users:

1. One or more tables for each collection (date acquired, price paid, etc).  Similar tables for "wish lists", etc.  The user should be able to create an unlimited number of these (although the effect might be simulated by "tagging").

With this basic structure (and I'm sure I've forgotten something), web pages could be easily built.  There are web servers that can be easily installed on Windows machines for purely internal use.  The really nice thing about SQL databases is that transforming the data as the design changes is really, really easy;  the laborious work is displaying the data.

Just thinking out loud.  Too much work, given the capabilities of DVD Profiler.

Quoting Ace_of_Sevens:

Quote:

I don't understand the difference between tables 1 & 2.

For example, there is just ONE "Gone With the Wind";  that's one entry in table #1.  There are numerous releases of it (at least 3 BD releases, plus numerous DVD ones);  that's one entry for each release.  Each entry in table #2 references exactly one entry in table #1.

Quote:

Quote:
3. There should be one or more DB tables for each "media" (eg, multiple movies/features on a single disc, box sets, etc).  This keeps the DB tables for #1-2 above, conceptually "clean" (and hopefully invariant).

So this would be the same level as we currently track?

Basically yes.  A "media entry" would reference one (typically) or more (multiple movies/features on one disc) release entries.  Some entries would contain UPC codes, and some disc IDs.  Perhaps this table would be split into two, based on that distinction.  Table #3 might (conceptually) have a "tree" structure.  This is the "complicated" table (or tables).

@ dkgibson:

You are doing a lot of thinking. Lots of good ideas. You probably wouldn't be surprised that most of those ideas have been kicked around for some time around here, from time to time.

(1) Regarding use of slots. I was simply pointing out that using the Slot field is exactly how you control being able to detach the physical sequence within the changer from the collection# sequence. That way you can play with collection numbers all you want, but not affect selecting the DVDs with LoadDVD. When you need to change a bunch of the fields, you can do it with BulkEdit.
(2) Regarding the CX960 - I am aware of the ability to select Slot#1 and index forward or backward. I don't have confidence that will lead to a reliable solution, but I do plan to experiment with it.
(3) The notion of SQL access to the Profiler database has been crawled over and over and over ad infinitum. One user's solution is a Plugin for keeping the XML export up-to-date automatically. Maybe take a look and see if that satisfies your needs. For other examples, take a look at the remote database sharing over IP and the php solution already available before asserting that "what we need is ...".

As far as the internal database design, I wonder how you could presume to conceive of a design "over the weekend" that would be superior to one that has been in development for years, resulting in the industry-leading solution. I suggest that you settle down, learn to get the most out of the existing product and the plugins, and then constructively contribute suggestions for improvements, or new tools and plugins.

As you begin to explore the community, you will discover that there quite a few experienced s/w and other professionals kicking around. We learn a lot from one another.

Oh, and BTW I wouldn't assume that the CX960 "crippling" we are talking about is accidential or unintentional. The fact that exactly what we want is available in a higher-priced model leads me to believe that the crippling was a marketing decision in order to extract higher profits from essentially the same technology packaged with different features. I'm sure you have seen your share of that during your career.

Quoting mediadogg:

Quote:
You are doing a lot of thinking. Lots of good ideas. You probably wouldn't be surprised that most of those ideas have been kicked around for some time around here, from time to time.

I'm sure that's true.  Unfortunately, most of my forum searches here time out before they find anything (including material that is clearly there), so I'm in the awkward position of opening topics that I don't know have been previously discussed.

Quote:

(1) ... When you need to change a bunch of the fields, you can do it with BulkEdit.

An excellent example of my comment above:  I was not aware of BulkEdit (thanks; I will check it out).  It's the (perceived) lack of ability to do such, that led me to suggest SQL access (and move my slot #s to collection #s).

Quote:

(2) Regarding the CX960 - I am aware of the ability to select Slot#1 and index forward or backward. I don't have confidence that will lead to a reliable solution, but I do plan to experiment with it.
(3) The notion of SQL access to the Profiler database has been crawled over and over and over ad infinitum. One user's solution is a Plugin for keeping the XML export up-to-date automatically. Maybe take a look and see if that satisfies your needs. For other examples, take a look at the remote database sharing over IP and the php solution already available before asserting that "what we need is ...".

I'll check that out as well;  thanks!  Unfortunately, there's no "import" capability (and I understand that's more difficult, due to validation issues).

Quote:

As far as the internal database design, I wonder how you could presume to conceive of a design "over the weekend" that would be superior to one that has been in development for years, resulting in the industry-leading solution. I suggest that you settle down, learn to get the most out of the existing product and the plugins, and then constructively contribute suggestions for improvements, or new tools and plugins.

As you begin to explore the community, you will discover that there quite a few experienced s/w and other professionals kicking around. We learn a lot from one another.

As I previously said, this was "off the cuff" and "thinking out loud".  I know well that the devil is in the details (not to mention that I'm sure there are issues that I'm not aware of).

Quote:

Oh, and BTW I wouldn't assume that the CX960 "crippling" we are talking about is accidental or unintentional. The fact that exactly what we want is available in a higher-priced model leads me to believe that the crippling was a marketing decision in order to extract higher profits from essentially the same technology packaged with different features.

Perhaps.  One tends to see that more in purely software products, than hardware products.  The latter is more often differentiated by hardware differences.  However, in the case of the CX960 vs. the CX7000ES, there's not much (at least in my mind) to justify the large price differential (which I suspect will drop).  One difference is of course the RS-232 connection;  another is 7.1 audio output (which the Sony site incorrectly shows as being available on the CX960!!!), and few other differences.

However, unless the CX7000ES has a user web interface, I'd say the evidence is very strong for a lack of imagination in design rather than any intention.  For example, I own a Harman-Kardon 3380 receiver.  Why did I pick that receiver?  Because the HK3380 was the only one I could find that allowed the frequency of an FM station to be entered via the remote control (if anyone knows of another one, please let me know).  Note the country of origin.  Since most receiver remote controls have a numeric keypad, this is not a hardware issue;  it is a software (lack of imagination) design issue.

It is well-known that certain cultures excel more than others various fields of consumer electronics and software design.  Often a culture that excels in one field, doesn't in another.  I can give numerous other examples.

Quoting dkgibson:

Quote:
Unfortunately, most of my forum searches here time out before they find anything (including material that is clearly there), so I'm in the awkward position of opening topics that I don't know have been previously discussed.

You'll have better luck using Google with "site:invelos.com" preceding your search terms.