Compact article view?

[UlrichKliegis]

Where has the option to switch to the 'compact article view' gone?

Cheers,
U.

[Quade]

There isn't one. They're compact by default now.,

[UlrichKliegis]

Hmm, if the single parts appear - is that a sign that they are not yet complete?

Image link not allowed for unregistered users

[Quade]

There are so many variations in posting it's hard to know. Not everything will compact. Some people refuse to use the standard posting methods. For example, they're required to use double-quotes around the filename but, they might not quote or use single quotes instead.

[UlrichKliegis]

Well, I happened to hit this example first. In other groups, the posters' behavious seems to be more well mannered.

Thanks,

U.

[mojo-chan]

Okay, a related question, how do I turn the compact view off? I find it annoying, I prefer to see everything by default. If it can't be turned off maybe it could expand all by default.

[Quade]

Can't. It's stored on disk compacted. 5.59 stored it on disk uncompacted so, switching back and forth was relatively easy. I've toyed with the idea of an "uncompact all option" but, it will cost easily 10 times as much RAM as it currently uses and will be relatively slow. Still thinking about it.

[UlrichKliegis]

Some nzb sources like http://www.binsearch.info/ seem to build nzb files that cause newsbin to store parts of the binaries posted in multiple groups just there, some parts in a.b.blabla, the rest is a.b.dingdong. Of course, this can't be blamed to newsbin, but sometimes it is a bit of detective work to recompose the parts. But I saw that nzb-induced downloads seem to be grouped better together now in 6.x, is that so? If yes, fine!

Cheers,
U.

[mojo-chan]

Thanks for the explanation Quade. From my perspective I mostly use either relatively low traffic groups or nzb files so I don't have a problem with speed or memory usage. My PC has 6GB of RAM anyway.

I know it must be tricky trying to support relatively light users such as myself and those who like to access groups with millions of articles, so I'd like to say thanks for keeping up the good work.

[UlrichKliegis]

Just add me to the thank- and respectful users' list! Image link not allowed for unregistered users

Cheers,
U.

[DThor]

Keep in mind that you can always select all then ctl-right arrow. I could assign that to single key equivalents, and with added products(my gaming keyboard, in my case) make it a single key macro. I would, except if you do that on fair sized groups, you find out really quickly just how much faster v6 is in this regard vs v5. I tried it when there were a few users complaining about missing it, to see what they were asking for, and it lasted one day.

Still, Quade did mention he's thinking about it, since even one key isn't the same as an option. Maybe on low volume groups as you mentioned it makes more sense. I'd still give the default method a chance, though - you might get used to it.

DT

[Murg]

I'd like to add my voice to making Compact View an option.

If turning Compact View on or off was an option, then it is up to the user to make the decision which way they want to see the headers.

Yes, I understand that it takes more memory and processor time. But, it is my memory and processor time, and I have plenty of both. Let me make the decision. For my typical view, it takes about a second to expand all of the headers, and 1% more memory.

Yes, I understand that the headers are stored this way in the database. But, Newsbin will uncompact the headers manually (Ctrl-A, Ctrl-RightArrow). So, it can be setup to do the expansion automatically. Let me make the decision, and not have to do extra work to undo a 'feature'. And, every day, when I do the Ctrl-A, Ctrl-RightArrow, I'll be reminded of this 'feature'.

I would rarely want to download an entire compacted header's files, as I don't need the par repair files. Yes, I don't use AutoPar/UnRar, but at least you give me the choice on this.

In addition, when a compacted header is expanded, there are two listings that are exactly the same: the Compact Header (Whatever.rar) and as one of the headers in the expansion (Whatever.rar, Whatever.r01). This is confusing, and will lead to the accidental downloading of the 'item' twice (once as the compacted header, and once as the individual files).

It is also difficult to scan the group for the content I'm looking for with the Compact View. Having the repitition of the uncompacted headers is what I'm looking for. In addition, especially with video, the compact view doesn't catch any of the sample files, so the 'main' header is further hidden by the noise of the files that miss being compacted.

[apsen]

I'd like to add my voice to making Compact View an option.

You could count my vote for this option too.

[Quade]

Alright, I'll think about it.

[Ace]

I tried the equivalent of that option (ctrl-a, crtl-right arrow) in a moderate sized group, with only 62000 compacted posts.

Before doing that, my total memory usage was about 1.2 Gigs out of 4 installed, and only a fraction of that was for Newsbin.

After doing that, the memory usage skyrocketed past 4 Gigs, and when it passed 5 Gigs it was doing so much paging Newsbin almost became unresponsive, it took about 2 minutes after i clicked on "file" for the menu to appear so I could click "exit". So Quade, you're right about the memory usage. It didn't seem to want to stop at 5 gigs either, it was still going up when I terminated Newsbin.

If you do add the option, one possibility to think about would be to check the newsgroup size or something like that. It looks to me like the large newsgroups could be a problem with that option on, even with 4GB installed.

Personally, I prefer the compact view, it's a lot less to scroll through.

[Quade]

To make the option usable, people will really have to restrict the "Display Age". For example, expand all on a 10 day display age might not be that bad. Doing it on a 200 day display age might be too much.

The other alternative is a re-write for how expansion works to try to reduce memory usage.

[Ace]

Doing it on a 200 day display age might be too much.

My display age was 1200, maybe that's why I had a problem. I had it set to 1115 but then I found some files I really needed at 1138 days old so I upped the setting to 1200 to be able to get those. The 62,000 posts uncompacted shouldn't have been more than a few million posts.

But you're right, a display age of 10 days would be no problem, at least in that group. But I think boneless is something like a million posts a day, so it still might depend on the group, 10 days in boneless might have more headers than 1200 days in the group I tested.

[Quade]

You can load up say, a 30 day span from 1200 days ago. That's what "Load Special" lets you do. I do "Load All" too but, it's not really needed if you have an age or date range you think your files appear in.

I've toyed with the idea of letting you load the group in segments from the GUI. Say, I remove "Display age" and a normal "Load" pulls in 5 days and you have a button, that lets you pull in the next span. You'd still be able to "Load All" or "Load Months" but, for causal browsing, the button would let you walk backward and forward in time through the group.

[Murg]

I tried the equivalent of that option (ctrl-a, crtl-right arrow) in a moderate sized group, with only 62000 compacted posts.

Before doing that, my total memory usage was about 1.2 Gigs out of 4 installed, and only a fraction of that was for Newsbin.

After doing that, the memory usage skyrocketed past 4 Gigs, and when it passed 5 Gigs it was doing so much paging Newsbin almost became unresponsive, it took about 2 minutes after i clicked on "file" for the menu to appear so I could click "exit". So Quade, you're right about the memory usage. It didn't seem to want to stop at 5 gigs either, it was still going up when I terminated Newsbin.

If you do add the option, one possibility to think about would be to check the newsgroup size or something like that. It looks to me like the large newsgroups could be a problem with that option on, even with 4GB installed.

Personally, I prefer the compact view, it's a lot less to scroll through.

This is pretty much the behaviour of V5.

If you are going to be loading a big chunk of a big group, you are going to have to have the resources to deal with it, or you are going to pay a penalty.

To make the option usable, people will really have to restrict the "Display Age". For example, expand all on a 10 day display age might not be that bad. Doing it on a 200 day display age might be too much.

Exactly. Not about the restriction of the display age, but about the effects of doing it on too large of a display age.

And, with large, fast memory available, and large, fast SSDs available, it won't be long before being able to expand something like 1200 of boneless will take very little time, relatively speaking.

The other alternative is a re-write for how expansion works to try to reduce memory usage.

I'm sure that it is much easier, in the short term, to just give us back the option to compact view or not.

If you want to rewrite the expansion logic, go right ahead, but it looks like there are a lot of other more important features to be added.

Doing it on a 200 day display age might be too much.

My display age was 1200, maybe that's why I had a problem. I had it set to 1115 but then I found some files I really needed at 1138 days old so I upped the setting to 1200 to be able to get those. The 62,000 posts uncompacted shouldn't have been more than a few million posts.

But you're right, a display age of 10 days would be no problem, at least in that group. But I think boneless is something like a million posts a day, so it still might depend on the group, 10 days in boneless might have more headers than 1200 days in the group I tested.

On a daily basis, I usually load up three days of set of large groups, with only the new posts visible. So, I usually have a day's worth of headers visible. Autoexpansion is not a problem with this size of headers.

For this set of headers, if expanded, I can scroll through the headers looking for what I want in a mind-less sort of manner, as the repetition of the multi-message headers triggers what I'm looking for. If the header set is compacted, I have to pay attention to the contents, and it also becomes a lot harder to separate the noise from the signal.

If I were loading up 1200 days of boneless, I'd want it compacted, as I'll probably be using search on that quantity of headers, and not scrolling through them. And if I scrolled through them, I would be paying attention to the content.

I've toyed with the idea of letting you load the group in segments from the GUI. Say, I remove "Display age" and a normal "Load" pulls in 5 days and you have a button, that lets you pull in the next span. You'd still be able to "Load All" or "Load Months" but, for causal browsing, the button would let you walk backward and forward in time through the group.

Yikes! This is want I'm talking about. You would be forcing the users to use the program a certain way, completely removing existing flexibility.

If you want to implement this, implement it along side the existing monthly load, not instead of it. If screen real estate is an issue, give the users an option to use one of the other, or figure out a way to combine them.

Since I load up three days of headers normally, this means that I'd be forced to go to Load Special to load any significantly larger chuck of headers. Loading an additional three days of headers at a time might be good for a press of the button or two (to go back a week say).