Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - patch

Pages: [1] 2 3 4 5 6 ... 8
1
Feature Suggestions / Re: New version?
« on: September 10, 2010, 02:41:10 pm »

 OK I am going to be politically incorrect, rude and pushy, and ask the question that I am sure a lot of people here have in mind......... When can we expect a new version from Nostra?
I know I shouldn't ask this, considering PVD is free for all of us (thank u thank u thank u), but I just can't resist!

Forum header says version 1 is in development which is a recent addition. Nostra has said the same also. So you already have your answer.

I suspect the real answer you wanted is when. I the past the answer has always been when it is ready. However as version 1 is a major upgrade it is likely to be a longer gap in time than recent minor version upgrades. So I suppose the answer is a long time yet as it was between 0.98 and 0.99

Edit:
Sorry deazo I should have read your post more closely.

2
Talk / Re: censored
« on: September 08, 2010, 12:41:22 pm »
How about leveling the playing field and providing others with moderator access so your rants and self indulgent posts can also moderated.
There really is zero chance of rick willingly allowing that to happen.
http://www.videodb.info/forum_en/index.php?topic=1429.0

3
Feature Suggestions / Re: Reviving the Wiki
« on: September 07, 2010, 11:15:41 am »
Unfortunately it seems like many users have difficulties when starting using PVD.

It's been a useful experiment, but the unavoidable conclusion is that no wiki is going to work very well in our circumstances.
Hits PVD Wiki Home :- English: 27432 Russian: 6802
Page Ranking English:
--PVD-Manual ie table of contants (11047) (Which was not easy to find in the old wiki)
--Launching-PVD-for-the-First-Time (4734)
Page Ranking Russian
--Руководство по PVD ie table of contents (2823)
--Запуск PVD в первый раз ie Launching-PVD-for-the-First-Time (2092)

You still haven't presented any concrete reasoning why this should be so.
Quote
we could scrap the idea of an HTML help file entirely. Instead, program help would simply run a search. This can be done now with a Web search like...

http://www.videodb.info/forum_en/index.php?action=search;advanced;search=help

Sorry rick I do not believe it is possible for me to explain the issues to you.

4
Feature Suggestions / Re: Reviving the Wiki
« on: September 07, 2010, 01:47:35 am »
I do not see much difference between forum and wiki in regard of providing help to the users. Both can be configured to provide similar functionality and it is equally easy to implement links to any of those in the application.
The useful wiki feature for online manual maintenance as I see it are
1) Good page version control tracking who has made changes and easy reversion of changes. This enables liberal delegation of edit rights, encouraging all users to contribute to documentation maintenance. In contrast to a forum where topic header edit rights require administrator privileges which are sensibly only granted to a small fraction of trusted users. The inability to directly fix the documentation without believing knowledge justifies being a moderator and existing administrators agreeing will not increase volunteers to maintain forum documentation.

2) Structures, providing efficient generation of lists / contents. The information content is language independent so only needs to be done once across multiple language versions of the manual

3) Language translation and tracking support is more refined, consistent with the wiki focus on maintaining a reference document vs the forum focus on tracking and storing conversations.

The end result is maintenance of a document in a forum is clearly possible. However it will end up being done by the moderators and in multiple languages. Not a problem for an organisation with a document writer. Also not a problem if nostra, rick and reset are comfortable writing and maintaining it. Or perhaps you are happy with the current level of documentation, noob users support, in which case moving in to the forum environment is probably not to onerous.

Quote
Rick has a good point: providing help topics in the forum is definitely less work to do.

Agree administering one site is going to be easier than 2

Quote
At the current state of things I would tend to use forum, but naturally, if some has time to provide a well structured wiki page I could reconsider this.
This maybe happening at the moment imo but that is open for debate.

Quote
I do not have time to study different wiki engines and such, so maybe I just do not see some kind of easy solution thou. Also, if someone has a step by step instruction of adding wiki functionality to the existing forum engine, then it could be of great help.
From what I have see software tends to do a forum well or do a wiki well but not both (imo). So doing both well would require the user logging into the forum and wiki independently if they wanted to write in either. (And yes I have looked at WikiStyle SMF theme. Similarly SMF Online Manual is OK as a manual and reads as if it was written by a documentation writer with the comments mostly asking for support and being referred to the forum, not suggesting updates to the help pages. This is a perfectly reasonable approach if if one person wants control of the documentation, it is just different to a collaborative document. Interestingly they run two copies of the forum software and require a separate login for each)

5
Feature Suggestions / Re: Reviving the Wiki
« on: September 05, 2010, 05:11:12 am »
look and feel should be technical feasible.
Was thinking mainly in terms of adding a Wiki site header with tabs on it similar to http://www.videodb.info and linking to locations here such as Download, forum, Donations.
This should remove the need for a whole pile of links which imply the user is at the wrong site.

Would be good to have a search box there to.

We would need to label the login as "Wiki Login" so as not to confuse it with the forum login here.
Similarly the title should be something like "Personal Video Database Wiki"

Quote
for me content, in a an accessible, logical format comes first - bells and whistles second.
+ there is the learning curve of making it happen.

I think what i have done so far is a good start and should make it a bit easier for users to find stuff.

I would really like to get toc / structure functionality working. That way displaying parts of the toc become trivial and ultimately easier to maintain.
The page ranking suggests that other users have found this format useful too.

I can see the structures OK. The PVD-Manual Structure is also visible apparently in edit mode, but I can not work out how to add any new pages.
I wonder if it is a protection problem as edit structure rights are probably off by default for wiki users.

Would be worth trying to run the clean structure comand at some time to see if it fixes the numbering problem cwdean was having.

6
Feature Suggestions / Re: Reviving the Wiki
« on: September 04, 2010, 12:38:03 pm »
Quote
The integration will be limited by having to maintain 2 logins and associated profiles however imo it could be a step in the right direction.
I don't understand this??

In an ideal world we could fully integrate the wiki and the forum.
I think nostra looked at it when the wiki was first proposed and decided the time investment it would take him to move the forum to a platform which supported a wiki would be too demanding on his time. So the wiki was hosted on different software, by a PVD supportive user. (Actually there were separate English and Russian wiki if I remember correctly which were then combined into one.) If this was to be reconsidered I have no idea what software would be used as the forum in tiki wiki looks inferior to what is currently used here.

A way of making the wiki appear to be part of http://www.videodb.info would be to make the home pages identical.
Most of the links on the wiki home page would then direct the user to http://www.videodb.info pages, except of course the wiki tab.
Where this fails though is the logins/registration are separate between the different sites/software.

None the less, a wiki home page which looks and feels similar to http://www.videodb.info/forum_en/index.php and mostly links to www.videodb.info has merit imo from an integration perspective. Nostra would have to not object of course.

The alternative is we just make it as good as we can make it in its own way. Nostra would then be able to later move new useful functionality back here later if he thought some new features had merit.

7
Feature Suggestions / Re: Reviving the Wiki
« on: September 04, 2010, 07:29:39 am »
I've not had much luck with table of contents. It is too hard to order contents easily.
I have found wiki trails work quite well to provide a logical order and can be used to create a table of contents automatically.

I don't know if tikiwiki has the functionality to do this. Unfortunately the mark up language is a lot different to what I use at work (pmwiki) and i'm still trying to work out its quirks. Im also trying to figure out what its feature set.

Where has everyone been looking to work out how to use "structures" which I think is what is behind the toc?

This tiki wiki structure manual page looks interesting
Problems with structure order is discussed here

btw, Like the header they have on the tiki wiki site and the all documentation page. I wonder how they do it. Makes me wonder if we could put the equivalent of the http://www.videodb.info header to increase integration and provide uniform navigation buttons.

The integration will be limited by having to maintain 2 logins and associated profiles however imo it could be a step in the right direction.

8
Feature Suggestions / Re: Reviving the Wiki
« on: September 03, 2010, 08:39:40 am »
Quote
I don't entirely agree - i think wiki would be for new users learning about the software, features  what it can do, learning the basics etc. Those who have used it for a while and have questions come here to the forums.

If they are "new users learning about..." then they're users, aren't they? And it's up to them to decide where they want to be. My point is the wiki must not pretend to be a second home for PVD. It's sole purpose is to provide help documentation for users of PVD. Users of PVD don't need a second introduction or sales pitch. Give them what they're looking for—without the bullshit.
A wiki is a community maintained reference document. Ideally suite to cover basic and advance features of software.
Putting various forms of help documentation is sensible. Help documentation would normally start with a program overview so that could be added as well. Basically anything the community could reasonably expect to maintain.

Of course breaking copyright without permission is unwise, especially with nostra.

Quote
I've made a few minor changes to the wiki that are, more or less, based on this idea. I put links to "PVD Home" and "PVD Support" at the top of the menu list. I don't care if they stay there, if there's a better way to "integrate" the two sites. I removed a few of the "fluff" features that add nothing to it's main function. I was tempted to remove the forum as well, but editors may want to use that to communicate with one another on wiki matters.

Four links on the wiki home page to http://www.videodb.info/forum_en/ is just silly.

imo we do not need 2 PVD forum. wiki suport can be done here. While it is true the multi lingual support is better with the wiki software that applies to all PVD communication.

BTW, you may want to clarify the likely future of the wiki with nostra before investing a lot of time in it. It's currently running like a ghost ship—hosted by someone we've had no contact with (AFAIK) for over a year. I would want to know what would happen to the wiki if the plug were pulled. I think it would be rather presumptuous to assume nostra would recreate it elsewhere. Aside from finding it ineffective and a PITA to maintain, this is why I was trying to discuss an alternative.

Yep we know you do not like the wiki rick and would like it to die.
However your Integrated Help Forum is not an alternative. Sure it will give the moderators / thread originators power trip but it will do nothing to encourage community participation in the arduous documentation task, and users will be left to wade through crap to find their answers. Forums and wiki have different strengths and weaknesses. They can compliment each other well.

9
Feature Suggestions / Re: Reviving the Wiki
« on: September 02, 2010, 10:58:49 pm »
i have updated wiki home - completely ripped off forum home page (sorry). :-[
I liked your previous home page, what happened to that.

Actually having two official PVD support sites is confusing which I think is the larger issue

10
Feature Suggestions / Re: Reviving the Wiki
« on: September 02, 2010, 01:00:47 pm »
Is there a hit counter on the wiki? Maybe users go there read the content and it is enough for them to do what they want to. Just because it is not updated does not mean its not working. Probably the opposite. If it is getting hits, it probably means the content is good and doesn't need to be updated.

There is a hit counter on each page see the page list

btw I quite like a table of contents which shows most of the available pages, the uniform hierarchy display as shown in the semi automatic contents is also good imo.

Not to say a linked contents could not also be used, I'm just not convinced I would like to use it yet.
Links from each PVD "menu option" / "menu bar option" straight to the relevant wiki page could be good though.

11
Feature Suggestions / Re: A few changes i'd like to see
« on: September 02, 2010, 11:45:16 am »
Only thing im missing now, is a subs display priority list! (so that when exporting, i can make a priority list, on what subs to display first)
Happy2k, I do not understand what you are meaning PVD could do and how you would use the new capability.

Are you trying to get your movies to play with your preferred subtitles by default? If so how does that work and shouldn't your play do this.

Or do you want PVD to display the subtitles with the one you are most likely to be interested in first. If so that sounds useful if not hard to implement in PVD.

12
Feature Suggestions / Re: Reviving the Wiki
« on: September 01, 2010, 10:53:46 pm »
I have thrown together a rough version usinging tikiwiki. (by no means professional but gives an indication of how it could work)
http://www.nimidia.com/pvd_wiki/tiki-index.php?page=UserPagecadishere
imo the content of your home page is better than the existing one so I would be in favour of replacing it with yours. Well done.

13
Feature Suggestions / Re: Integrated Help Forum
« on: September 01, 2010, 12:40:51 pm »
Quote
You participate enough here to understand how the forum software works
Yes and this is why I don't think it is an adequate tool for a help system. Unless the moderator (you) reads every single post in a topic and takes relevant info out and puts it into 1st post, then users have to read through potential crap to get to the bit that explains how to do something and it means a lot of work for moderator (you) in editing posts.

Yep that is the main issue with maintaining a dynamic document in a forum. Only moderators and the thread creator can maintain the opening post. Works fine if the thread creator owns and wants full responsibility for maintaining it. However it actively discourages peer co-operation in favour of a hierarchical approach.

Having the primary entry into the wiki pointing to the contents page would go a way to fixing the current one. Better still if a search box was added to it.

As I've already said, the purpose of this topic is to discuss a completely different alternative to wikis. If you would like to discuss how to fix the wiki, please start another topic.

This does, however, illustrate the need for an alternative. The author of the wiki recognized the need for this "entry point" into the wiki. But then he abandoned the project before completing this after thought. If the wiki were being used and anyone interested in contributing to it, someone would have finished what he started.
No
The table of contents is part of the wiki, a dynamic document so by definition it is never going to be complete. Yes it was started by cwdean but it is editable like any other wiki page so we could continue to improve it.

My point was it is already a better point to take users to who select the wiki tab in this forum or in PVD. Neither of which I can change.
The current home page is OK for those coming to the wiki from the internet as then introducing the project is more relevant.

14
Feature Suggestions / Re: Integrated Help Forum
« on: August 31, 2010, 11:58:00 am »
Quote
Configuring the wiki (or any alternative wiki) to be "more PVD centric" (whatever that means) does nothing to address the issue.

I disagree. I have had great success with developing a wiki in at work. It does need to be focused on its purpose for existing and needs someone to take ownership and drive it.

Quote
more PVD centric" (whatever that means)
I mean by this, all the crap needs to be removed and content focused on PVD.
IMO -The wiki focus should be more of a Content Management System with wiki features.
+1

Quote
Quote
the help file would only contain links from the program hooks to topics in a forum. They would be organized in a hierarchical manner—a table of contents.
I see some flaws here:
* someone needs to maintain the links in the forum
* multiple posts would need to be maintained.
* users would need to wade through multiple posts to fin the information they are after.

Document management is always contentious. No one like writing "how to" doco.
From experience, I think a wiki style system would work. it needs to be focused and have features to do other stuff (like act as a CMS, produce pdfs etc). The forum still exists to discuss and fix etc, but when a solution is found, all the discussion is removed and the core solution is added to the wiki.
+1
Having the primary entry into the wiki pointing to the contents page would go a way to fixing the current one. Better still if a search box was added to it.

The Forum is the best way of exploring new or difficult issues. It is easiest to create as it is just a record of conversations by those who choose to converse that way.

A wiki produces a more readable reference document. Enabling new users to go straight to the current preferred answer on documented subjects and anyone who feels the current documentation could be improved can directly fix it. It does however require a conscious effort to contribute to PVD documentation and some effort to maintain the structure / contents page.

A help index goes some way to bridging the gap but is not as good (from a readers perspective) as a wiki table of contents and the referenced forum threads are not as good as an equivalent wiki page.

15
Feature Suggestions / Re: A few changes i'd like to see
« on: August 29, 2010, 08:43:43 am »
It would be alot easier if PVD just grabbed the poster directly from the folder. As a new user to PVD, its not very easy getting to work, as it is now. And if you dont know how .bat files works, then youre screwed.

Enhanced PVD capability to read (and write) locally stored movie information has been discussed on several occasions
http://www.videodb.info/forum_en/index.php?topic=1441.msg6116
http://www.videodb.info/forum_en/index.php?topic=1249.msg4630#msg4630
http://www.videodb.info/forum_en/index.php?topic=870.msg2037#msg2037

But unfortunately I think WYSIWYG http://www.videodb.info/forum_en/index.php?topic=870.msg5587#msg5587

16
Support / Re: Multi threaded IMDB fetching?
« on: August 28, 2010, 09:48:21 am »
So do you think running multiple versions of the program, each simultaneously running the plugin, would be a valid test of whether IMDb would tolerate this kink of hammering?

From an accessed site perspective what is suggested will demand the same or less than the current approach so the risk is low there.
The concurrency happens at different web sites.

Running multiple versions of PVD partially tests a much higher risk implementation imo.

Quote
Quote
As such documenting program use instructions in a forum is the opposite to what we need.

I, of course, disagree with this. We have a wiki. It doesn't seem to be used much, and there's quite obviously no one with any interest in contributing to it. So the evidence seems to be to the contrary.

The suggestion was to address nostra's observation that the perceived PVD complexity is a significant barrier to a new novice user.
Quote
Unfortunately it seems like many users have difficulties when starting using PVD.
I agree we all tend to be more interested in addressing issues relevant to what we do. Unfortunately the issues are different for the novice compared to a regular forum contributer.
The form is a good way to explore new and complex problems.
It is not a good guide for a first time user who just want to try out PVD to see if it meets there needs. Many will walk away.

So we interpret the evidence differently.

17
Support / Re: Multi threaded IMDB fetching?
« on: August 28, 2010, 05:25:44 am »
Quote
But i really like PVD - it was hard getting to work properly in the beginning, but the possiblities are endless.

Unfortunately it seems like many users have difficulties when starting using PVD. If you have suggestions how to make the process easier for beginners, then feel free to post in the Feature Suggestions board.

I suspect the problem is there is a trade off between a programs ease of use and its flexibility.
What we could do is focus on new users initial experience because if this can be made positive then many will see reason to put in enough time to see the benefit of the more advanced features.

Some ideas to help achieve this:
1) Wiki should open on a contents and search page focused on PVD not the wiki engine.
2) Clear simplistic tutorials for basic initial set up tasks.
3) Let advanced users have to burrow through multiple pages to get to relevant things for them rather than beginners. As such documenting program use instructions in a forum is the opposite to what we need.

18
Support / Re: Multi threaded IMDB fetching?
« on: August 28, 2010, 05:07:15 am »
The idea of running in parallel is fine—assuming each field is filled using only one source.
In option 1) above the plugins for an individual movie are run in series ensuring all the current data dependencies are preserved. ie with time on the horizontal axis

movie 1 imdb -> movie 1 allmovie -> movie 1 amazon
--------------> movie 2 imdb      -> movie 2 allmovie  -> movie 2 amazon
----------------------------------> movie 3 imdb      -> movie 3 allmovie -> movie 3 amazon

Resulting in all sites being accessed in parallel. The how to do this is what the separate tasks and queues were for in the earlier post.

Quote
Even more problematic is the idea of getting only data for fields that need it. (I'm not sure this is what you meant, but it's implied by "maybe a lot faster for later incremental updates to an established PVD database.") Data changes. The only way to determine whether data needs to be updated is to compare it to what's currently available. So it's faster just to download all the data.

It would be helpful if fields set to "ignore" were omitted.
Currently for each field we can specify,
a) Solid tick -> get value and overwrite existing value
b) Grey -> store value only if no prior data (so really only need to get in if field is currently empty).
c) White / blank check box -> do not use this value (so no need to get it).

For populated field b & c do not need to bee downloaded, for an unpopulated field c doesn't need to be downloaded.
The potential saving depends on the granularity used by each sites web interface and how slow a particular page is to download. For example images, full cast list and deeper technical pages etc.

19
Support / Re: Multi threaded IMDB fetching?
« on: August 28, 2010, 02:13:00 am »
Quote
Multi threadded IMDB fetching

That's an interesting idea for other reasons (e.g., update speed), but I would be very surprised if IMDb did not ban IP's making multiple simultaneous requests. I'm actually surprised were able to get away with what we are doing.

Before using PVD, i was trying out different programs. Most of them had a very fast IMDb fetch. I dont think IMDb would care - ive never heard of IMDb ip banning someone.
I wouldnt mind being a ginniepig for testing out multi threaded IMDb fetching.

I strongly suspect most time is spent waiting for the remote web sites to respond and downloading data.
PVD is likely to be slower than some other programs as it downloads more data.
Trying to increase the download speed by having multiple requests from the same user / program going to these databases is likely to cause more maintance problems as the html request stream generated will put further stress on these remote databases, not generate income fore them, and differ more from a browsing user for which they were designed / marketed at.

Things which are at least theoretically possibly
1) Run different plugins / web site queries in parallel. By this I mean if for a movie you are getting information from imdb, allmovie, and amazon then the sites could be accessed in series but the 3 sites could be accessed in parallel by overlapping accesses for different movies. Implementing this would probably mean calling different plugins from different tasks with a queue between each so involve considerable change to the plugin calling code but less changes to to individual plugins. Maximum speed up of x3 for 3 plugins run in parallel.

2) Only information which is going to be actually stored in PVD could be downloaded. By this I mean PVD could look at the field flags set for the plugin and the data already in PVD and determine what pages actually need to be downloaded for each website - PVD movie update. The speed benefit would be minimal when initially populating an empty PVD movie record from the first web site, so would be no faster than 1) for a mass movie import but maybe a lot faster for later incremental updates to an established PVD database. From a coding perspective it would be a major change to the plugin architecture with each plugin being passed information on which fields need to be filled, them each plugin being code to selectively download web pages as required for each PVD movie record update. So it implies a re-write of each plugin for which selective access is practical and considerable changes to the plugin calling code.

Of course I have no idea how hard any of this is for nostra but the theoretical discussion is still interesting. None of it sounds easy to me so I'm not confident any of it will be implemented.

20
Support / Re: Multi threaded IMDB fetching?
« on: August 27, 2010, 11:48:47 pm »
Tutorials would probably help alot. A video tutorial on how to add movies, series and how to fix common errors.

Better still, update the wiki while you are still learning and have your best appreciation of a beginners experience.

Pages: [1] 2 3 4 5 6 ... 8