You've encountered two important facts about planning:
1) Priority and value are not the same thing. You have a number next to each story. If those numbers do not have the property that 10 stories with the number 1 next to them are worth more than 1 story with the number 5 next to it, then the number next to each story does not represent value, at least not on an arithmetic scale. In which case don't call it "value". If those numbers do not have the property that greatest value is achieved by working on the story with the biggest[*] number first, then the number next to each story does not represent priority. In which case don't call it "priority". Unless the numbers somehow contrive to have both properties at once, don't call them "priority/value".
2) The numbers are only vague approximations anyway. Also, depending where the numbers came from, things might have changed since the time when someone wrote a number next to the story. So any process that just crunches the numbers will sometimes not give you the right answer.
You want to do the thing with highest value to the customer, which is fine. Your instinct in a particular case might that the 5-point story would have higher value to the customer than all 10 1-point stories. That is to say, your instinct is that the numbers you have really do represent priority, not value. That's also fine. If you're doing Agile then you have direct access to the customer pretty much at all times[**], so you can easily check whether your instinct matches that of your customer. You can also check with the rest of your team. If so then proceed with what you collectively believe to be highest value.
There are circumstances where the customer would prefer the 10 small fixes over the one big fix. For example this would happen when many of the small things are annoying on a day-to-day basis, while the big thing is a new feature that will be lovely when it lands, but everyone is getting on without it. Then you would do a sprint designed to improve general quality of life rather than to deliver "the next feature".
But, whichever is the "right answer", if the numbers written next to the stories don't give you the right answer, then they don't represent what they claim to represent, and you should not kid yourself, your team, or the client, that this is what they represent. You can't do good work by blindly following bad numbers. So, either write down better numbers or else pay only very loose attention to the numbers and do what you all agree is right.
[*] or smallest, if priority 1 is the most prioritous!
[**] this is the logical contrapositive to the statement, "if you can't check in with the client then you aren't doing Agile, so don't kid yourself you are". The "client" here might be some stand-in for the actual fee-paying customer, especially for software that has a very large number of paying customers. But if you can't talk to at least a nominal customer then you're not agile.